Bug in release build but not in debug build
Author
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?
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
So - just initialize your pointers to NULL so you're able to test wheter they point to something or not.
Oxyd
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.
Author
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?
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?
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... ;)
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... ;)
Author
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.
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.
well, then i'm sorry. :(
Bugs like that are really really anoying. I know it just toooooo well. ;)
Good luck finding your bug! (Hey that's a rhyme =)
Bugs like that are really really anoying. I know it just toooooo well. ;)
Good luck finding your bug! (Hey that's a rhyme =)
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
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
Author
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
