debugging CTD due to only xml changes?

[davidlallen]

Thanks! That may well be the solution to this particular crash. Many types of missing reference errors are caught by either, an xml parsing error or a crash at time zero. This type of crash is different because it occurs randomly during runtime. I have come across this type of crash in many different situations, where I know unit upgrades were not the problem.

Perhaps what is needed is some preprocessor to check for missing references. Ideally, the game should do this itself; but clearly it does not. Does anybody know of such a preprocessor?

 

[davidlallen]

OK, I wrote the preprocessor. I found a few missing references in my crashing files. Before these changes, it would crash 100% of the time in the first 100 turns. Now, it crashes 20% of the time in the first 100 turns and there are no missing references.

Please see the updated zipfile at this link. I have included a crashing save game file. I used autoplay; if you start BTS with this game file, it will start at turn 92 and autoplay until turn 96, when it crashes. Or, you can start any game with any settings, autoplay 120 turns, and "probably" get a crash. You should not have to try more than 5 times.

To go back to the non-crashing version, two steps are now required in the CustomAssets/xml/units directory. First, copy units-noncrashing.txt to CIV4UnitInfos.xml. Second, delete or rename CIV4UnitClassInfos.xml. Now you can run 5 games or more with no crash.

Any debugging tool which can help solve this will be greatly appreciated.

 

[deanej]

I noticed in Civ4BuildingInfos you set the aqueduct to have fVisabilityPriority set to a very large number. The game probably can't handle it properly. All other buildings have it set to 1, so it may not be intended to be changed.

 

[davidlallen]

That is true. However, I have not added or changed anything in these entries. I have just copied the BTS file and deleted all the buildings I don't want. The BTS aqueduct has the same visibility setting. I don't know why it is there, but that is not causing the crash.

 

[davidlallen]

The pre-processor or checker which I wrote may help other people with this kind of problem. I am still having the crash I described and there are no missing references, so there is something else wrong. I could use some help debugging that.

The checker is described further with a download location in this thread.

 

[Yakk]

My advice? Recompile the default SDK DLL as a Release build with debugging symbols included, then install it in your mod directory.

Launch the game. Attach a debugger to your game process after launch. Run the game until you get a crash. Look at the call stack of your game.

It might give you a good hint.

...

Another way of approaching this would be relying on your mod being built out of small pieces, each tested, and then you move on and add another piece. A "change history" that lets you back up and undo a change to see if the crash goes away... But that is a process problem that is harder than simply debugging an already existing implementation.

 

[davidlallen]

@Yakk: That is a good suggestion. I have never looked into the SDK code but I am an experienced programmer; maybe I could make something out of it. My understanding is that the only way to compile the SDK is to use Visual Studio 2003, which is free, and does not include a debugger.

So, what tool would I use to compile the SDK and debug it? If I were to get a debug build created by some kind soul, I would still need a debugger.

Regarding your suggestion of making changes in small pieces, that is also a good idea, but it cuts development down to a crawl. I spent a solid 8 hours trying to cut down the tech tree so that it would not crash. I took out four techs, it crashed, I put back in two techs, it didn't crash, I tried to figure out what about the other two techs might have made it crash, etc. Very indirect and painful. In the example I have discussed earlier in this thread, the change I made was to remove 100 units. It is conceptually a simple change, but I still have not been able to figure out which one, or handful, of removed units is actually causing the crash.

 

[Yakk]

Hmm? I wasn't aware there was a Visual studio install that didn't include a debugger.

2005 isn't that far off from 2003 -- have you tried downloading express 2005 and seeing if you can get it to compile?

Sadly, 2003 express cannot be downloaded anymore.

 

[davidlallen]

@ Yakk: what do you use? According to the long thread in the sdk sticky area, the code does not compile under Visual Studio 2005 or anything newer.

 

[Yakk]

I use 2003.

 

[davidlallen]

Using my civcheck program, I have improved the stability quite a bit. The example I gave earlier in this thread is still crashing 20% of the time, and I would appreciate suggestions on how to debug. However, in my actual mod, I have fixed some missing references and now my actual mod seems quite stable. I have autoplayed more than a dozen games out to 400 turns with no crashes or hangs.

The main type of missing reference I found was units that could upgrade to a unitclass, but the default unit for that unitclass was not defined. For example, warrior upgrades to the axeman unitclass. The axeman unitclass exists, and it refers to a default unit axeman. But the axeman unit does not exist, and furthermore no units of unitclass axeman exist.

I would have hoped that the game engine would flag that the axeman unitclass refers to a non-existing default unit. But it does not flag.

Bottom line, use civchecker to find undefined symbols before you try running your mod. There is some other problem I cannot find, but it is much less frequent.

 

[deanej]

Thanks for releasing civchecker!!! It diagnosed a memory error in my mod that I've had no idea how to fix ever since BtS came out!

 

[davidlallen]

Excellent. For my future reference, what was the specific problem?

 

[deanej]

In Civ4LeaderHeadInfos, what was meant to be FLAVOR_GROWTH was instead FLOVOR_GROWTH.

 

[davidlallen]

Really? Before, you were getting random crashes, and after you fixed this typo, you were not getting any more crashes? We'll never know, but I wonder why that particular typo would have caused a crash. The kind I was having, I could see that it might try to upgrade a unit, and then crash because the code wasn't expecting to fail to find a valid unit type.

 

[deanej]

No random crashes. Just a memory error when the mod exited to the desktop.