Rob Landley wrote in a message to Wim Veldhuis:

> Sorry to butt in, but I think there is a better way :-)
> 
> What I (under Windows) do is the following. I start the debugger and let the
> debugger run the app. When an exception occurs, the debugger is invoked in

 RL> With wild pointers, the exception sometimes occurs FAR away
 RL> from the cause.  Then you have to start removing large
And that usually results in the exception. All I said is that when you
validate the offensive pointer (registers) and step through until you hit
source code (Borland automatically shows it when it is there) you can see
which line caused the exception. After that comes of course the hard work
of figuring out why it was bad. At least it has the advantage of knowing
what is screwed up. (There can be more screwed up of course, but this is
not (yet) important.
Next time you try, you set a memory changed watch to see which statement
caused the memory to be invalid.

 RL> blocks of code to narrow it down to what exactly you screwed
 RL> up.  (I once copied a structure using the sizeof() the wrong
 RL> structure (the data file header structure instead of the
 RL> data file record structure) and overwrite some memory,
 RL> corrupting the dos memory chain.  It worked fine until the
 RL> program exited and tried to free the memory, at which point
 RL> dos said "the system has been stopped."
So this is not an exception error, and thus have to be handled differently.
And I know these are difficult to find.

 RL> You can easily trash your own structures, variables, etc,
 RL> and trying to figure out what you did wrong by looking at
 RL> the assembly language (which you didnt' make, the compiler
 RL> made), is doing it the hard way.  Unless you've got a
 RL> compiler error (which I have encountered), it's easier to
 RL> pick it out of the source code than the .exe.

I agree with you here , but my point was of getting the portion of
source code to check. The rare cases where I really needed the assembler
was where I thought everything must be correct and the result is not what I
expect. For instance I say a=1 and get an exception on the address of a.
This former case was in a windows proc that did not have an export
qualifier :-( and accessed a module global variable. Instead FWIW, the
program has about 10.000 lines and it happened while handling a batch of
(window) messages. I would not have found it so soon (approx 1hrs) without
a debugger (and some assembler).

Finally, Microsofts CodeView just doesn't want to execute any statement
after receiving an exception 13. Here you are almost completely lost in
these cases.


mvg/wr
  
--- timEd/2 1.01.g3+