Crash - Assert Failure

Joined
Feb 3, 2011
Messages
608
BAH WRONG SECTION! Could some mod please move this to regular Civ4 Creation and Customization forum?

----------------------------

I got my mod to crash today, which hasn't happened in like forever.
It was crashing on next turn button clicking mid game.
Loaded up the Debugger dll and it would not even load my saved game - crashed instantly with following message:

Assert Failure in file FFreel...Array.h line 372
Expression: m_pArray[iIndex].pdata = NULL

My mod is not even that fancy - it just Commerce mod SDK from Saiboleh and the rest are bunch of xml only add-ons , like units, tech, buildings, etc.
The only things recently added was ocean features and a new line of promotions.

Any one got ideas?

Thank You!
 
I hate that kind of assert messages because it tells that it crashed due to some out of bounds access to an array, though it doesn't say why it is called with the wrong argument. The only thing to do in a case like that is to use the debugger to check the callstack and that way backtrace where the wrong number originates from. Or at least figure out which list is causing the issue. The problem is most people can't use the debugger. It doesnt' work on the steam version and those with the disc version tend to have issues figuring out how to use it. It's a task for experienced C++ programmers.

While it is a problem inside the DLL, it can be triggered by invalid xml settings. Say for instance you have 10 unitclasses and 2 units for each (20 units). You then enter unit 15 at a location where it expect a unitclass and with a max of 10, you can quite possibly cause an assert like this one. There is an endless number of combinations, which can cause something like this and I will not even start to guess without more info.

This is true for all games using the civ4 engine, be it bts or colo.
 
Using the debug DLL doesn't debug the game automatically. What it does is it enables asserts and it disables optimization. Disabled optimization allows you to connect the debugger.

In this case the call stack is the important one as it reveals where the call came from. The call stack is the topic starting at 12:00, though I recommend watching the whole thing if you don't know how to debug.

When encountering an assert failure, clicking debug will act as a breakpoint if you have the debugger attached. This means you rarely have to set breakpoints when debugging the DLL.
 
Top Bottom