I got a MSVC debugging question too....
 

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.........

Re: I got a MSVC debugging question too....
 

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]

Re: I got a MSVC debugging question too....
 

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.

Re: I got a MSVC debugging question too....
 

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

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

Re: I got a MSVC debugging question too....
 

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.

Re: I got a MSVC debugging question too....
 

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

Re: I got a MSVC debugging question too....
 

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 ;)

Re: I got a MSVC debugging question too....
 

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.

Re: I got a MSVC debugging question too....
 

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

Re: I got a MSVC debugging question too....
 

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

Re: I got a MSVC debugging question too....
 

Ha! Found the bastard!!

It hit me today while I was at work - the path table I create for the bot is causing the problem: a memory bounds exception.

It worked fine for small maps, but on big maps there wouldn't be enough room in the table for the bot's complete path, and maps like MP_TRENCHTOAST are pretty big (which happens to be the only map the game crashed on btw), while smaller maps like MP_DESTRUCTION (which is what I originally created it on) have had no problem at all. So the path created for the bot would be too big for the table, and would end up stomping on other things, causing the crash.

Thanks for the help guys! The release build runs perfectly now!