COMPILE: Getting really frustrated with crash

[Locutus]

Asmodean,

Yes, John has the game working perfectly, but it's a pity he seems to be just about the only one

John,
Well, normally I should be the one to create the packages of new patches, so you don't have to worry about that That is, assuming we can get this annoying crash fixed

Regarding the movie logo, I guess we could cut the Activision logo out of the intro movie, that should only take about 10 seconds for anyone with the right software (not counting the time to load and save everything ). I think even I could do that. But I'm not sure if it's really worth the trouble -- it would mean that everyone would have to download a 30 meg large file just to get rid of a stupid logo. But if anyone were ever to design a cool new intro movie, I'm all ears

[J Bytheway]

I've uploaded a diff file:

http://apolyton.net/csd.php?http://apolyton.net/upload/files/J%20Bytheway/Ctp2diff.zip

This is the diff between a version of the ctp2_code directory which I believe is original, except for me compiling the Debug Browse version of crater.dll, and my current version of the ctp2_code directory. The information you seek should be in there somewhere...

If anyone has any other iideas as to how we could compare, I'm open to suggestions.

[MrBaggins]

Thanks muchly, John. I'm going to check this out as soon as possible.

[MrBaggins]

Findings from diff file.

Nothing earth shaking... the following are the apparent differences in the source files (all which we essentially know about):

ctp2_code/ctp/civ3_main.cpp obvious added disclaimer
ctp2_code/ctp/ctp2_utils/c3errors.cpp=cd check stuff
ctp2_code/ctp/ctp2_utils/c3errors.h=disclaimer message box header alterations
ctp2_code/ctp/display.h= #include multimon.h
ctp2_code/ctp/dll/map/Crater.dll= binary file differs?
ctp2_code/ui/interface/NationalManagementDialog.cpp= added fix for rushbuy

The following, however are the differences in the flex and byacc compiled files (or I guess they are created from there)

ctp2_code/ctp/eventcb.txt=different, based on where compiled?
ctp2_code/ctp/slicdbg.txt=different numbering no idea why?
some... not all of the .stamp files differ in numeric values

===

So.. my thoughts? I don't see any significant source file difference to speak of- I've added the change to display.h and thats the only theoretical problem that I see could cause the crash. The rest are new additions or pre-existing bugs.

The differences in the manual compile stuff bothers me.

It could be I'm doing that wrong, but I don't see how. Why would it fail if I did a debug build, then a final build, with the #include change?

Incidentally I've gotten two consistent warnings on two lines in debugcallstack; unreferenced local variable definitions, solved by putting inside ifndefs, but they don't change solve anything either way.

I've done manual and automated flex/byacc etc. Same result.

So... possible differences.

*Different DirectX build. Possibily. I'll check, and try if different. You were using '03 summer?
*Different miles.h and mss32.lib. Which ones are you using, John?
*Different manual compiled files, somehow. The only way to see if its this is to get those files.

My ideal solution would be to copy the (working) directory to another location. Run the uninstall for it. Which will remove any unchanged files. Remove the exe's, map files and the contents of the final directory.

That should leave the 'different' files.

Zip/rar that up (multipart to 5 Megs, I guess, if necessary), including full directory paths.

I'll install a fresh source into there, then copy the contents of the zip over the top.

That should solve it, I guess... I hope...

[J Bytheway]

I was indeed using DirectX '03 summer. If you look at the chat transcript I believe Locutus and I discussed this in detail.

I'm using the miles.h and miles.lib from the first post of the "Success with the sound" thread (note that they did change, I got the latter versions).

I presume the crater.dll difference is due to one being a final build and one being a debug browse build, but I'm not sure.

The slicdbg.txt is generated at runtime and depends on what SLIC code is being loaded.

eventcb.txt I knownothing about, essentially.

Doing as you suggest has some problems: The DX stuff in the directory structure will make it huge, and I'm slightly worried about screwing up my own setup now I have it working. I'm also running low on disk space, so it gets hard to make lots of backup copies and so forth.

Differing DirectX versions still seems the most likely cause, or some other more subtle variation in our setups...

[J Bytheway]

The following post might be pertinent to these problems:

http://apolyton.net/forums/showthread.php?postid=2468144#post2468144

[MrBaggins]

I reinstalled the Summer release of 9.0b. Copied the new libs in.

New debug build, then new final build, and it crashes.

Exactly the same spot.

Odd since the regular game and that exe you produced work.

I really don't have any clue how to proceed, particularly since the problem is seemingly causing a debugger crash (but other debug situations don't)

[MrBaggins]

I, by the way, did have the later miles.h and mss32.lib, but recopied them just to be sure.

[MrBaggins]

BTW... I haven't mentioned this recently, but I'm getting really quite significantly frustrated with this.

The code I've done at work from scratch, or in a team has never been this kind of a problem.

[J Bytheway]

I guess you can try to narrow down the exact time of the crash by putting in messageboxes everywhere (use c3_errorDialog, or whatever it's called). I was doing that earlier when I thought the debug build was stalling.

My personal attempts at C++ code usually run into the kinds of problems I can't track down as soon as I'm linking different files together...

[Locutus]

I've been trying to locate the source of the mysterious crashes by adding the test message "c3errors_ErrorDialog(NULL, "test");" in various places in the code. This hasn't lead to a solution yet, but I have established how the proces of loading a new game works:

The function CivApp::PostStartGameAction can be called from a number of places in the UI files and adds a startGameAction to the action list, which aui_UI::HandleActions (which continously runs: it is called from the aui_UI::Process, which itself is called from CivApp::ProcessUI, which is in turn called from CivApp::Process, which is called in the main while loop of CivWinMain in civ3_main.cpp) then picks up and runs by calling StartGameAction::Execute. This calls the civApp::StartGame function, which calls CivApp::InitializeGame, which actually sets up a new game.

The crash does not occur in the CivApp::InitializeGame function itself, this completes just fine. So do civApp::StartGame and StartGameAction::Execute. Putting a test message after the last command of the for loop that handles the startGameAction event (in aui_UI::HandleActions), displays this message correctly. So the problem does not appear to be in the handling of the startGameAction event. It is not possible to place test message in the main body of aui_UI::HandleActions or its caller aui_UI::Process, as these functions are part of a while loop and are executed continuously while the game runs. The game would probably be interrupted by error messages millions of times before getting to the point of the crash, if you'd even get there at all.

The cause for the crashes appears to be in one of the main process functions (I suspect in CivApp::Process), not in the code that sets up a new game. The next course of action would seem to be to create/use a test message system that writes test messages to a log file, so that test messages can be placed in the various Processes, to see when exactly the crash occurs without interrupting the game. Currently I don't have time for this though.

Does anyone have ideas on how to best place test message in the Process functions? Maybe someone else who's experiencing the same crashes can pick things up from here? If not, I'll continue myself when I have time again.

[Fromafar]

If you are using a debug build, you can log information with DPRINTF statements. Have a look in civ3_main.cpp for some examples. These will be logged to civ3log*.txt files in the logs directory, and seem to be created automatically.

[child of Thor]

'civ3_main.cpp' ? you don't mean that do you, or else no wonder they were after CTP2 so much in the courts

[The Big Mc]

yes they did there some text files to

[Locutus]

If you are using a debug build, you can log information with DPRINTF statements. Have a look in civ3_main.cpp for some examples. These will be logged to civ3log*.txt files in the logs directory, and seem to be created automatically.

That's the whole point: the crash doesn't happen in the debug build. Only in Release and Final...