Debugging (was: F9X twister & ADA)

["James Giles" <jamesgiles@worldnet.att.net>]

Geoff Bull wrote in message <38F53816.3D1F28A6@research.canon.com.au>...
>James Giles wrote:
>
>> >What about buffered io and user defined buffering?
>>
>> Like all parts of the program's state, those are all still present
>> *in* the debugging file.  You can inspect them there.
>
>But I'd prefer it in a place defined by me!
>I hate looking at core dumps and, thankfully, since using
>Ada I *never* have to - same for Java. (when I was a C/Fortran I
>lived in the debugger, I get the impression you are still stuck there )

That sounds very inconvenient to me.  If I had to design a replacement
for what the system produces as a 'dropfile' or 'core file' (or whatever
it's called in your system) it would have to be about the same.  It would
contain all the data that such things usually contain or it would be
inadequate (leaving out important parts of the context of the failure).
This apparently happens to you: since you've made it clear that
a halted program, in whatever environment you're using, loses the
register contents present at the point of failure.  What else are you
losing?

And, if I were forced to invent a browser for going through the
corpse of a failed program, it would be very much like a debugger
(usually displaying data in terms of the program's source, etc.).
The only difference from usual debuggers would be that I would make
the core image editable and restartable.  That way I could often
correct and restart a long running program rather than have to
rerun it from scratch after finding the problem.  I've done this often
on systems that implemented editable and restartable program
images.

Since most of what is necessary to do would be very similar to what
the systems people have already done for core images and debuggers,
it would be very inconvenient to have to reinvent it myself.  Do you
have to do this on a program by program basis?

>In any embedded / real time context your proposal is just plain wrong.

Not during program development.  That's the context I have
very clearly been discussing.  I have clearly stated that for
released code for general naive users, some form of graceful
termination is important.  For embedded/real-time code (which
we haven't discussed before), no form of termination is appropriate:
the code has to continue to run (though maybe in an impaired way).

You can always invalidate someone's position by changing the
context of the  discussion, but how does that further any objective
analysis of the problem at hand?

>Stop dead on exception would be difficult to implement if the
>program is multithreaded or distributed across multiple machines?

Nope.  The thread that fails stops immediately.  All others stop at
the next rendezvous.  Why would that be difficult?

What I want is that combination of features which most increases the
likelyhood of finding the error quickly and allowing me to continue
working (either developing code, or working with my in-house
production code).

--
J. Giles