Sign in to follow this  

Bug in release build but not in debug build

This topic is 4689 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

I have some kind of memory corruption error (I think) but the most odd part is that it doesn't happen in debug builds. It happens pretty quickly in release builds. Most of the settings are the same for both, such as turning off optimizations completely, because I want to minimize the difference between the builds. I have some debugging conditionals in there, but I turned off the flag for those, too, and they no longer appear in either build. I've done almost everything I can think of to remove differences, but the problem still exhibits this oddity. Does anyone know what could change between build modes that could cause this kind of thing?

Share this post


Link to post
Share on other sites
It's because in debug build uninitialized variables are set to the value of zero. This, however, doesn't happen in release build, so you have just some random garbage in your uninitialized pointers (they are variables too...). And when you do something like if (ptr != 0) doSomethingWith (ptr); and ptr hasn't been initialized yet, you get segmentation fault (ptr is invalid, but not zero).

So - just initialize your pointers to NULL so you're able to test wheter they point to something or not.

Oxyd

Share this post


Link to post
Share on other sites
Also, in debug builds, some compilers like to add extra bytes to the beginning and end of arrays. It protects from memory corruption of sorts. But in release, those buffers aren't present and important data is accessed when arrays are over/under-run.

Share this post


Link to post
Share on other sites
Thanks for the info, guys! I'm using VC7.1 under Windows XP.

This crash happens pretty randomly, so that's what leads me to believe it's some kind of buffer overrun damage.

Is there any way to ensure that the compiler isn't padding buffers in the debug mode?

Share this post


Link to post
Share on other sites
you should write a basic logging system so you can see where your program crashes.

Also make your file writing stuff out on the fly (i mean not buffered) to ensure
that everything up to the crash-point will be written to the file.

The Enginuity series on this site by 'superpig' has a nice Logging class.
Try it! It's teh roxx0rs... ;)

Share this post


Link to post
Share on other sites
Thanks for the tip. :)

I already do both of those things, though, and I know where it crashes, but that doesn't tell me where the problem originates, unfortunately. The trouble is a corrupted pointer. I'm trying to figure out what is corrupting it (randomly) and why it doesn't get corrupted in debug builds.

Share this post


Link to post
Share on other sites
Ok, so it's a certain pointer that's getting messed up. Tracing the pointer can be a bit of a problem.

One of the solutions is to place breakpoints on strategically places in your code. Once these breakpoints are set, change the condition of the breakpoint to "... has changed", where you replace ... with the name of the pointer.

If you start doing this on of the top level loops of your app you can slowly trace when the pointer is being damaged. It maky take some time, but you'll find it eventually.

Toolmaker

Share this post


Link to post
Share on other sites
Thanks, Toolmaker. I'll keep that in mind as I continue along.

I've discovered that if I run the release build from debug mode within Visual Studio (F5), it doesn't crash, just like the debug build. What the heck is changing?!

I'm not well versed in the minutiae of the debugger, which I guess doesn't help things.

Share this post


Link to post
Share on other sites

This topic is 4689 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