I got a MSVC debugging question too....

[Maleficus]

I'm having a problem where the "release" build of my code will randomly crash after a while (completely random - or so it seems), but my "debug" builds can run day and night with no problems.

I know its probably a variable I didn't initialize properly, but the question is WHERE.

I've added SO much bot code, and modified so much of the game code since the last release, thats its like finding a needle in a haystack. I checked the option to create "debug" info in the release build, and now when it crashes it lets me see what function it crashed in (just the function name, then the assembly code), but that doesn't help - this function is called EVERYWHERE, but both my code and the game code. I've checked the call stack to see which functions ran last, but its just not giving enough info: it looks like its skipping functions that should have run in between what the call stack info shows.

Is there an easy way to find where a bug is in a release build? Its creeping up on 2 in the morning here and I just feel like I'm missing something.........

[sPlOrYgOn]

maybe it can be a memory leak that causes the error to be show like it came from somewhere else.. if not you should add whatever code to try and prevent the crash or add "_asm {int 3};" right before where it crashes and run in debug mode then follow through the assembly code as it runs 1 step at a time..
[edit]
another possibility is that you got stuff like #ifdef _DEBUG #endif..
maybe you got some stuff-that-should-go-inside those things, outside.. or something-that-goes-outside, inside...
[/edit]

[Maleficus]

But wouldn't a memory leak show up in a debug build too? Like I said - the debug build is rock solid, it will run for hours and no problems.

[Maleficus]

Checked my _DEBUG defines, didn't see anything amiss.

I've been checking all my variables, but nothing so far.

[Maleficus]

btw: heres the call stack info

QAGAME_MP_X86! Distance + 13 bytes
QAGAME_MP_X86! Mal_AI_NodeMoveToGoal + 39 bytes
QAGAME_MP_X86! MAL_AI_FindLTG + 130 bytes
QAGAME_MP_X86! Mal_BotAIStartFrame + 179 bytes
QAGAME_MP_X86! G_RunFrame + 760 bytes
QAGAME_MP_X86! vmMain + 176 bytes
WOLFMP! 00441ad2()
WOLFMP! 00445bc0()
KERNEL32! bff7b9e4()
KERNEL32! bff7b896()
KERNEL32! bff7a24f()




vmmain and Runframe are the not mine, they are the main functions in the game code. Distance is just a function that returns the vector lenth of a vector. Its used everywhere. From this, it appears nodemovetogoal was the function that called distance, and caused the crashed, but I've checked whats being passed to distance from that function, and its not invalid. The crash is somewhere else, I think - yet.... it ALWAYS says it happened here!

Hmm.


ALSO - there about half a dozen different functions that are run before the node movement code is called, but they don't appear in the call stack list.

[Rick]

There is an option to enable auto setting variabeles to 0, you could search the name of the option on MSDN and disable it with debug mode

[Pierre-Marie Baty]

Hahaha, I know that.

The difference in MSVC between DEBUG builds and RELEASE builds, is that when you allocate new variables or memory stuff, MSVC automatically zeroes it out when it's compiled with DEBUG. In RELEASE, your variables are all uninitialized, i.e in unknown state.

Memset all your arrays & buffers, I bet that's it

[koraX]

also in DEBUG mode, MSVC allocates more memory for arrays than needed, usually one more element. That is because of zero indexing.
If you create int a[3]; and then access fourth element a[3]=1;, it won't cause access violation in DEBUG mode.

[Rick]

Originally Posted by Pierre-Marie Baty

Hahaha, I know that.

The difference in MSVC between DEBUG builds and RELEASE builds, is that when you allocate new variables or memory stuff, MSVC automatically zeroes it out when it's compiled with DEBUG. In RELEASE, your variables are all uninitialized, i.e in unknown state.

Memset all your arrays & buffers, I bet that's it

yes....So if you disable this in debug mode perhaps you can find out where the problem is...

[Maleficus]

Originally Posted by Rick

yes....So if you disable this in debug mode perhaps you can find out where the problem is...

Good idea - now to find out what that option is. I'm searching thru online MSDN, but have never found their help very... helpful.