Prev: Microsoft Responds to the Evolution of Online Communities
Next: DDX_Control DDX_Text window control help
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!

First  |  Prev  | 
Pages: 1 2 3
Prev: Microsoft Responds to the Evolution of Online Communities
Next: DDX_Control DDX_Text window control help