Archived

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

okonomiyaki

Crashing in release, not debug.. sigh..

Recommended Posts

I''ve tried to hours to debug this problem. I have gotten absolutely NOWHERE. I''m using Visual Studio .NET 2003. I compile my program. I run it in debug mode. It works fine. I''m testing a GUI that involves listboxes and textboxes. I then run it in release mode. After 15 seconds the program crashes (like a memory protection error). It happens at various places, usually I can get past the first screen or two, but it always ends up crashing. It works ''perfectly'' fine in debug. I know that debug mode may compile it with safety checks and different machine code... but how in the world would I debug something like this? I really need some suggestions, as this big project is due next Tuesday and I''m really burned out right now Thanks a lot everyone!

Share this post


Link to post
Share on other sites
do you have a logfile?
you should be ble to debug anything like that without the help of a debugger.
if you can access a console, just throw in some printf or whatever to localize the crash. (if you haven''t already)

Share this post


Link to post
Share on other sites
I nice version to make it crash is to check pointers for non-null on startup. In debug they''ll be set to 0xcdcdcdcd while in release they can be 0, but can be anything else too.

Debugging release is ugly, usually they best way is to use heavy logging. Add "log i''m here" and "log i''m at pos b" and if it crashes in between draw the two logs closer. Trap the crash

Share this post


Link to post
Share on other sites
I''ve had problems like this before where debug mode runs and release mode doesn''t. I''ve found this to, in my cases, always be the result of uninitialized variables. In debug mode variables and initialized to standard value, in release mode they aren''t initialized and could be anything.

Share this post


Link to post
Share on other sites
Unitialized variables can give this result.
Also try it without global optimization. If it works, then you probably have errors in function calls.

Share this post


Link to post
Share on other sites
quote:

do you have a logfile?
you should be ble to debug anything like that without the help of a debugger.
if you can access a console, just throw in some printf or whatever to localize the crash. (if you haven''t already)



I have tried this, somewhat at least. I quit because it varied when it happened, sometimes it happened when typed a letter in a textbox, sometimes it happened when I am searching the listbox for text. I supposed this is only real way to deal with it though, as there might even be more than 1 wrong place.

quote:

Also try it without global optimization. If it works, then you probably have errors in function calls.



Yeah, I tried that, but it still didn''t work. So I''m guessing it''s something with an uninitialized variable somewhere... I usually have a good habit of doing that though

Thanks a lot everyone.

Share this post


Link to post
Share on other sites
You don''t by any chance have multiple threads in your program, do you? Or use any libraries that often create their own internal threads? ''Cause threads can be a great source of unpredictable errors like this. Often caused by not carefully synchronizing code with events, mutexes, semaphores, or whatnot.


Most of the greatest evils that man has inflicted upon man have come through people feeling quite certain about something which, in fact, was false.

-Bertrand Russell, Unpopular Essays, "Ideas That Have Harmed Mankind"

Share this post


Link to post
Share on other sites
i''ve never had a problem debugging in release mode (MSVS.NET C++ apps). build release -> F5 to run -> debugger breaks out on line with error... do other people not find this to be the case?

-me

Share this post


Link to post
Share on other sites
I had that problem before when trying to delete memory in a deconstructor that was already deleted. Go back and look at what memory you are clearing and make sure it has not been previously cleared. Another thing to watch for is what you have changed recently. Did you just add something to make it start causing the problem? If so, go back and look at the code again.

-UltimaX-
|Designing A Screen Shot System|

"You wished for a white christmas... Now go shovel your wishes!"

Share this post


Link to post
Share on other sites
One thing I use is
try...catch blocks

Put at the highest level, they can catch the code regions in which the crashes occur. & then you can drill down with more try...catch blocks

int dgbnum = 7000;
try
{
Code section 1 here

}
catch(...)
{ /// Open "CodeSec1dbgnum.txt" file to hard Drive & close
dgbnum++;
}

try
{
// Code section 2 here

}
catch(...)
{ /// Open "CodeSec2dbgnum.txt" file to hard Drive & close
dgbnum++;
}

Share this post


Link to post
Share on other sites
quote:
Original post by Agony
You don''t by any chance have multiple threads in your program, do you? Or use any libraries that often create their own internal threads? ''Cause threads can be a great source of unpredictable errors like this. Often caused by not carefully synchronizing code with events, mutexes, semaphores, or whatnot.


Most of the greatest evils that man has inflicted upon man have come through people feeling quite certain about something which, in fact, was false.

-Bertrand Russell, Unpopular Essays, "Ideas That Have Harmed Mankind"


In fact, I do. But I don''t really deal with any synchronization issues. The thread is a network thread that takes in packets and puts them in a queue. Then the program calls another function that checks to see if the queue is not null. No real problem there, eh? There shouldn''t be an great mutex problem or such.. I am skeptical though.


quote:

I had that problem before when trying to delete memory in a deconstructor that was already deleted. Go back and look at what memory you are clearing and make sure it has not been previously cleared. Another thing to watch for is what you have changed recently. Did you just add something to make it start causing the problem? If so, go back and look at the code again.



I''m thinking something like this could definitely be an issue as well. I have a macro that safely deletes data, basically it says

#define SAFEDELETEARR(x) if(x != NULL) { delete[] x; x = NULL; }

I should try to make this macro do nothing (which should take all deletes out) and just see what happens. Thanks!

I may try putting in a couple try/catch blocks as well. Thanks a lot guys.

Share this post


Link to post
Share on other sites
quote:
Original post by okonomiyaki
In fact, I do. But I don''t really deal with any synchronization issues. The thread is a network thread that takes in packets and puts them in a queue. Then the program calls another function that checks to see if the queue is not null. No real problem there, eh? There shouldn''t be an great mutex problem or such.. I am skeptical though.



Yes, you should definitely use critical sections when accessing the queue. Anything more complex than reading/writing a single integer from different threads needs synchronizing. That is becuase if there''s a threadswitch in the middle of some update, there''s a good chance that the datastructure is in an invalid state.

quote:

#define SAFEDELETEARR(x) if(x != NULL) { delete[] x; x = NULL; }



You don''t need to test for NULL, delete and delete[] does nothing on NULL pointers. But setting the pointer to NULL after the delete is almost always a good idea.

Share this post


Link to post
Share on other sites
quote:
Original post by fredizzimo

You don''t need to test for NULL, delete and delete[] does nothing on NULL pointers. But setting the pointer to NULL after the delete is almost always a good idea.



I do not know about that Codewarrior will not throw an exception however it will throw an "Access Violation" that does not crash the app. Found out its a failure to test if null.

Share this post


Link to post
Share on other sites
quote:
Original post by afterburn
quote:
Original post by fredizzimo

You don't need to test for NULL, delete and delete[] does nothing on NULL pointers. But setting the pointer to NULL after the delete is almost always a good idea.



I do not know about that Codewarrior will not throw an exception however it will throw an "Access Violation" that does not crash the app. Found out its a failure to test if null.




Strange, because the c++ standard says in 5.3.5/2
quote:

In either alternative, if the value of the operand of delete is the null pointer the operation has no effect.



No exception, no error, no other sideeffects should happen. And this behaviour has been there since c++ was born, so I find it very strange that codewarrior would be different. Free in c, behaves in the same way too.

Edit: The only case I can think of when it goes wrong is if someone has overloaded either the global delete operator, or the delete operator of the class. And don't account for null values.



[edited by - fredizzimo on April 23, 2004 6:09:54 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by UltimaX
I had that problem before when trying to delete memory in a deconstructor that was already deleted. Go back and look at what memory you are clearing and make sure it has not been previously cleared. Another thing to watch for is what you have changed recently. Did you just add something to make it start causing the problem? If so, go back and look at the code again.

Inapproppriate cctor and pass by value.

Share this post


Link to post
Share on other sites