Sign in to follow this  

"Start Without Debugging" causes program crash in Release mode

This topic is 2835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey all, I've been pretty perplexed by this problem I discovered today. It seems that when I run the program in release mode using "Start Without Debugging", it crashes at some points during execution. It's hard to pin down exactly what points in it's execution that are causing this: sometimes it's when a player gets hit with a projectile, sometimes it happens during an AI update, sometimes it's neither of those. I can attach the debugger after the program is started and it will give me a message like: "First-chance exception at 0x773f75ff in icggame.exe: 0xC0000005: Access violation reading location 0x91939397." Sometimes it points to a location in the source code and sometimes it doesn't. When I first discovered the problem, the program was crashing immediately after starting it. I did some research and ended up recompiling libogg and libvorbis to use their dynamic version instead of the static version and this caused the program to run a bit before crashing. Trying to isolate the issue further, I took out all the sound code. Right now I'm just using OpenGL with freeglut, compiling with Visual Studio 2008 Express Edition. I have some suspicion that the crashing is being caused by a race condition. However, after outputting the beginning and end times of the glut callbacks, it seems as though the callbacks don't overlap at all and there is only a single thread (I'm not sure how exactly freeglut handles the glut callbacks). So I've sort of ruled this out. In addition, sometimes when the debugger does give me a point in the source code where the crash occured, it will occasionally point to an STL library. This makes me think that it has something to do with the Code Generation Run-time Library option. Originally my program was set to "Multi-threaded DLL". However, I checked freeglut, and freeglut was being compiled with "Multi-threaded". Thinking that I need to make these all the same, I changed my program to "Multi-threaded", to no avail. If anyone has had a similar issue or any recommendation on how to go about debugging this problem, I'd love to hear it. Thanks.

Share this post


Link to post
Share on other sites
Debug mode provides initial values for all variables. i.e. 0xcccccccc. Meaning that "undefined behavior" is often predictable in debug mode (and mightn't result in a crash), but the program runs differently in release mode.
Try changing the compiler settings. Run in release mode with optimisations off, then try with runtime checks enabled, etc.

Share this post


Link to post
Share on other sites
It does seem like it has something to do with the heap. I've narrowed the problem down to one line: 'new'ing a projectile derived class. In the section of code which creates projectile when an actor is attacking, there is a place where I basically call (for example) "new ProjectileBullet( ..params.. )". If I take this line out, then the code runs without crashing. If I 'delete' the projectile immediately after 'new'ing it, the code runs without crashing. If I allocate the projectile on the stack, the code runs without crashing. Otherwise, the code crashes after about 9 allocations. I've checked that the allocation doesn't return NULL, and I've also tried to catch std::bad_alloc but it doesn't seem to be thrown. I should also point out that the program doesn't crash during the 'new' --- it crashes sometime much later in it's execution. The strange thing is that even if I let the new projectile dangle (that is, don't add it to the list of projectiles) it still crashes. This is making the issue pretty difficult to track down. It seems to imply that I'm corrupting the heap.

Also, I tried to enable some of the run-time checks for the release build but it didn't help.

Share this post


Link to post
Share on other sites
I'm very pleased to announce that I've solved the issue. It was indeed due to heap corruption. I found a few mentions on the internet of a program called Application Verifier that might be able to help and it has been invaluable. App Verifier pointed me to a place that I never would have found otherwise (some model loading code accidentally accessed two floats passed what had been allocated). Thanks everybody.

Share this post


Link to post
Share on other sites

This topic is 2835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this