I always assumed everyone used release mode, at least when they had finished making their project anwyway.
For a start the executable doesnt contain a ton of pointless debug crap (hence about 3 times smaller), but most importantly I guess is that your programs will run much faster.
For some reason I have been led to believe that debug and release modes use memory in different ways, hence my concern that my problem is due to freak memory issues.
How to debug in release mode? (vc++)
Pretty much every debug/release discrepancy I''ve ever had is from an array overflow. Debug, as noted above, pads your memory so that if you go one or two spaces above your allotted space, nothing will happen. Do this in release, though, and you will get a crashed program. There are two ways to debug something like this, while retaining your release build (which will run faster): do the write to file or screen statements along the lines of "Now entering function X" and "Now exiting function X." This will allow you to at least determine when your program bites the dust. The second, somewhat easier but less exact method is to go through every array and add a few extra spots in memory, one at a time. If any of the changes result in the program not crashing, you''ve found your culprit and then can figure out whether you actually need more space in memory or if it''s actually a bug.
------------------------------------------------
The wind shear alone from a pink golfball can take the head off a 90-pound midget from 300 yards.
-Six String Samurai
------------------------------------------------
The wind shear alone from a pink golfball can take the head off a 90-pound midget from 300 yards.
-Six String Samurai
quote:Original post by GekkoCube
what is the benefit of running in release mode?
i''ve noticed a smaller executable, but thats about it.
in one of my applications the release mode runs significantly faster than the debug. i don''t remember but i think it was like 200-300% faster. i guess that''s just an exception, my current project runs < 3% faster.
release mode. by default (since you can change the behavior) will:
1. remove debug informations, such as symbol tables. this prevents others from seeing your varible names, as well as greatly reduces file size.
2. optimize code. this greatly increases speed of excution. this removes ALL sanity checks and runs the code as is. meaning you MUST init your varibles before use or you wull get garbage vaules (they will NOT init to 0 as in debug mode). memory allocation is not strictly checked and writing to non allocated pointers results in bad things. going out of bound by even a byte will cause your app to crash (assuming you are leaking into memory you dont own, otherwise you are even in worse crap). things like freeing freed memory will croak you as well, you MUST set freed pointers to NULL and check to make sure you dont double free pointers.
there are other things that occer as well, but you get the idea. basically if your app crashes in release mode, you screwed something up and need to start debugging. since its not because the compiler is doing something different, its more of you doing something inherently wrong. memory (aside from some extra checks by the debug libs) is alloced/freed exactly the same. access is also exactly the same. if you get crashes, you are doing something wrong and have a bug that will eventually manifest itself in a debug version eventually (depending how the code is organized for instance adding a single line may push where the memory is allcoated in a debug version so that the crash will also occer in debug builds). so do yoru self a favor and check ALL memory accesses to ensure that you dont do silly things.
personally i always work with release mode until i get a crash in which i cant track using logging or zen. i will then switch to debug mode and step through the trouble spots.
only bad or careless programmers need to worry about the release mode version crashing.
1. remove debug informations, such as symbol tables. this prevents others from seeing your varible names, as well as greatly reduces file size.
2. optimize code. this greatly increases speed of excution. this removes ALL sanity checks and runs the code as is. meaning you MUST init your varibles before use or you wull get garbage vaules (they will NOT init to 0 as in debug mode). memory allocation is not strictly checked and writing to non allocated pointers results in bad things. going out of bound by even a byte will cause your app to crash (assuming you are leaking into memory you dont own, otherwise you are even in worse crap). things like freeing freed memory will croak you as well, you MUST set freed pointers to NULL and check to make sure you dont double free pointers.
there are other things that occer as well, but you get the idea. basically if your app crashes in release mode, you screwed something up and need to start debugging. since its not because the compiler is doing something different, its more of you doing something inherently wrong. memory (aside from some extra checks by the debug libs) is alloced/freed exactly the same. access is also exactly the same. if you get crashes, you are doing something wrong and have a bug that will eventually manifest itself in a debug version eventually (depending how the code is organized for instance adding a single line may push where the memory is allcoated in a debug version so that the crash will also occer in debug builds). so do yoru self a favor and check ALL memory accesses to ensure that you dont do silly things.
personally i always work with release mode until i get a crash in which i cant track using logging or zen. i will then switch to debug mode and step through the trouble spots.
only bad or careless programmers need to worry about the release mode version crashing.
Author
Thanks for the help, I made it write to file whenever it entered/exited any function, and hopefully I have fixed the problem.
I was using bad values in my call to glTexCoordPointer, telling it that I was using 3 coordinates, when I was using only 2.
I presume this was causing the problem as it hasnt crashed since.
Cheers
I was using bad values in my call to glTexCoordPointer, telling it that I was using 3 coordinates, when I was using only 2.
I presume this was causing the problem as it hasnt crashed since.
Cheers
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
