Re: Program crashes when running it outside dev environment
- From: Johan Bengtsson <qwerty_42@xxxxxxxxxxx>
- Date: Sat, 09 Jun 2007 12:18:30 GMT
z wrote:
I use Visual C 2005 to develop my programs. One in particular isDoes it fail when the debug version is run outside the environment, or is it the release version that fails?
crashing in very specific and hard to replicate situations, made worse
by the fact it only crashes when run -outside- the dev - as an exe,
not from the Debug option. If I try to launch the debug on the
crashing program, it'll close before the debugger opens. Any
suggestions as to how I should proceed? Thanks in advance.
If it is the release version, a possible suggestion is that you actually can debug the release version as well, but some things might be *very* strange in the debugger (like freshly assigned variables keeping the old value and so on because it is not stored to memory yet, understanding of assembler is a plus in those cases)
To pinpoint an error location outside of the environment could be possible doing either of those:
for GUI apps:
MessageBox(...);
MessageBeep(...);
for console apps:
printf(...); or fprintf(stderr,...);
(replace ... with proper code...) Of course the first two are very platform specific.
When all else fail I usually put a pair of those statements in suspected top level functions, one at the beginning and one at the end of each function like this:
void somefunction(void)
{
MessageBox("somefunction...","",MB_OK|MB_ICONINFORMATION);
/* the body of the function */
MessageBox("...somefunction","",MB_OK|MB_ICONINFORMATION);
}
This obviously won't work well for functions called lots of times unless they crash fairly fast in program execution.
When a function is pinpointed I put in more message boxes in that function in key places and so on...
For console apps fprintf(stderr,...) using the same basic technique could be used instead, I don't know if it would be a good idea to add a fflush(stderr) to each call... Someone else here could probably answer that if necessary.
If it just fails strangely and sometimes inside system functions it might be overwritten memory or some such problem. I use to put statements like this at key points in my program to find the real reason:
ASSERT(AfxCheckMemory());
(ASSERT only works in debug version however, if you want to do this in the release version you have to alter the code to some similar)
AfxCheckMemory() is probably very microsoft specific and not at all portable, but you don't want to keep them there once the problem is found anyway because they takes some time to execute.
Put one of those lines immediately before the line that crashes the program. If the ASSERT fails you have a memory corruption problem somewhere in your program.
If that is the case I put pairs of those in each top level suspected function. If it crashes on the top one the problem is elsewhere, if it crashes on the bottom one it is in that function...
If you have multiple threads also it might be a real nightmare to debug... Try to shut of parts not needed.
.
- References:
- Prev by Date: Re: Is it better to use a macro or a function?
- Next by Date: Re: How many levels of pointers can you have?
- Previous by thread: Re: Program crashes when running it outside dev environment
- Next by thread: gcc Preprocessor (-E) with comments
- Index(es):
Relevant Pages
|
