Archived

This topic is now archived and is closed to further replies.

harryx

How to debug in release mode? (vc++)

Recommended Posts

My program only crashes when run in release mode, so I cannot find out where it is going wrong. Is there any way to use the debug information given in release mode to find out where it went wrong in my code? Thanks

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

Not really.

Try printing out or wiriting to a file to narrow down the lines that are crashing your code.

Release only crashes are usually because you used a variable with allocating or initializing it. Debug puts default values in variables, but release mode does not.

Share this post


Link to post
Share on other sites
First, put exception handlers in your code (have a message box pop up with an error description, for example). Then go back to debug mode and watch your variables in that routine/scope. Look for any variables that remain uninitialized, etc.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
Thanks but I think my problem is slightly nastier than this.

I am creating and deleting a fair number of texture objects in opengl, and I think that this is causing my memory to become fragmented which is leading to this problem.

Its either that or the fact that I am also creating and deleting a large amount of geometric data, which could also be causing it.

Id just like to know which it is...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by harryx
Thanks but I think my problem is slightly nastier than this.

I am creating and deleting a fair number of texture objects in opengl, and I think that this is causing my memory to become fragmented which is leading to this problem.

Its either that or the fact that I am also creating and deleting a large amount of geometric data, which could also be causing it.

Id just like to know which it is...





It''s neither. That would also crash you in debug if it crashes you at all. You''re probably reading from a block of memory without writing to it first, deleting something before you were really done with it (Debug sometimes is OK with that) or accessing past the end of an allocated chunk somewhere (Debug also lets you get away with that, since it tends to ''pad'' your memory.)

Fragmentation has nothing to do with it.

Share this post


Link to post
Share on other sites
If you''re using MSVC, you can add debug info to a release build by going to Project->Settings, change "Settings For:" to Win32 - Release, goto Link and check "Generate Debug Info". Next, go to C/C++ and change "Debug Info:" to "Program database for Edit and Continue".

Recompile and you should be able to see all the symbol names and whatnot. Just be away that when stepping through optimized code, the cursor may jump around a bit as the compiler may remove/rearrange code for better performance.


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
Quite right Dean. Also, you can only really tell for sure what function you are in--the compiler is free to do all sorts of whacky things, so even watch symbols can''t be trusted half the time.

Share this post


Link to post
Share on other sites
Thanks for the help,

I set up release mode as suggested, however when I hit f5 and start debugging (in release mode) I dont get the crash - although I do if I start with ctrl+f5 but then I dont get any useful debug info.

Basically generating debug info in release mode seems to avoid the crash in the same way as running in debug mode does.

The crash is seemingly random (ie I can test it once and it will crash, I then copy exactly what I did before and it doesnt crash)

This is why I was thinking it is something obscure like fragmented memory.

Any ideas?

Share this post


Link to post
Share on other sites
what is the benefit of running in release mode?
i''ve noticed a smaller executable, but thats about it.

~ I am a DirectX to OpenGL convert! ~

Share this post


Link to post
Share on other sites
quote:
Original post by GekkoCube
what is the benefit of running in release mode?
i''ve noticed a smaller executable, but thats about it.

Non debug libraries (generally), for one thing, which are what clients/end-users are likely to have installed. If you released a commercial application built using debug libraries, only developers with those libraries installed would be able to run them.

Also, release mode strips out the debug information which a cracker could find very useful...

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites