Application disappears without any crash dump
in [Win32 API]
|
From: Charlie Gibbs on 5 May 2010 19:19 In article <1509753c-6b6d-4459-8db0-13597ede8843(a)h37g2000pra.googlegroups.com>, rsharma.champ(a)gmail.com (Rahul) writes: > Thanks Alf, > > So infinite recursion and large stack based array's seems to be the > problem. But why does the default debugger not catch these crashes. > I even tried on the system where Visual Studio was installed, It also > failed to catch those exceptions (unless we run the program the inside > debugger itself) > > Is there any way to catch these crashes without running the program in > the debugger, and why are they not caught by the debugger by default > (just for understanding the technical difficulty involved in this). My favourite way of dealing with these things is to define a buffer on either site of the local variables: void myfunc () { char buffer1[512]; ... other local variables ... char buffer2[512]; memset ((void *) buffer1, 0, sizeof (buffer1)); memset ((void *) buffer2, 0, sizeof (buffer2)); ... code ... } Often that's enough to stop the mysterious disappearances. You can then check "buffer1" and "buffer2" at various points in the code to see whether they suddenly become nonzero. That should catch simple overflows, but a truly wild pointer could clobber the stack far enough away that nothing bad happens until the program exits. Still, it's a start... -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
From: r_z_aret on 6 May 2010 16:14 On Wed, 5 May 2010 10:58:29 -0700 (PDT), Rahul <rsharma.champ(a)gmail.com> wrote: >Thanks Alf, > >So infinite recursion and large stack based array's seems to be the >problem. But why does the default debugger not catch these crashes. >I even tried on the system where Visual Studio was installed, It also >failed to catch those exceptions (unless we run the program the inside >debugger itself) > >Is there any way to catch these crashes without running the program in >the debugger, Adding ASSERTs to do sanity checks on pointers just before they are used can trap many pointer problems. This is less painful if done while coding. With luck and thought, you might be able to add them iteratively now: add some in places most likely to trap an error, keep adding until one triggers, then use the one that triggered to choose where to add more. Repeat as necessary. ASSERTs to test arrays that might be clobbered give less direct clues, but are better than nothing. And some clues you see while running a program point more directly to an array. Adding some way to monitor progress of the program can help you find the part of your source code that causes a crash. I've used calls to MessageBox. I add at least one to code I'm pretty sure runs before the crash and at least one to code I'm pretty sure runs after the crash. And after each crash, I narrow the gap between calls. This is very low tech, and seems painful. But often enough, I can rather quickly narrow the gap enough for me to see the likely problem, blanket the code with ASSERTs, and/or step through with a debugger. > >Thanks >Rahul ----------------------------------------- To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message). Robert E. Zaret, MVP PenFact, Inc. 20 Park Plaza, Suite 400 Boston, MA 02116 www.penfact.com Useful reading (be sure to read its disclaimer first): http://catb.org/~esr/faqs/smart-questions.html
From: Charlie Gibbs on 7 May 2010 12:32
In article <5u56u5d7vl1qqkmlq2jgk6i5jnmg0rati9(a)4ax.com>, r_z_aret(a)pen_fact.com (r_z_aret) writes: > Adding some way to monitor progress of the program can help you find > the part of your source code that causes a crash. I've used calls to > MessageBox. I add at least one to code I'm pretty sure runs before the > crash and at least one to code I'm pretty sure runs after the crash. > And after each crash, I narrow the gap between calls. This is very low > tech, and seems painful. But often enough, I can rather quickly narrow > the gap enough for me to see the likely problem, blanket the code with > ASSERTs, and/or step through with a debugger. If you narrow it down using a kind of binary search, the process can indeed be fairly fast. A variation of this is to #ifdef out chunks of your code, if necessary replacing them with a dummy routine that inserts needed values. Once you get the program to stop crashing, start re-enabling sections of code until it resumes crashing. Again, a binary search technique can speed up the process. A possible fly in the ointment (which applies to any technique that adds or removes code) is that the clobbered memory location might move to someplace non-critical, giving the illusion that you've found the bug when it's really just gone into hiding. -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign! |