🚀 go-pugleaf

In article <46g46d$aeg@fsuj01.rz.uni-jena.de>, vkk@rz.uni-jena.de (Karl Kleine) writes:
|> Robert Dewar (dewar@cs.nyu.edu) wrote:

[Robert Dewar's excellent points about debugging snipped]

|> It is considered bad USENET style to quote such long text, but Robert just
|> spelled out the important things, so you better read it twice!
|> 
|> The point I want to make: I went back from industry to teaching last year,
|> and in my introductory programming courses (based onm Modula-2) I do NOT
|> introduce a debugger. I insist on CONSTRUCTING programs, not fiddling until
|> it works. The debugger is sketched and demonstrated towards the end of term
|> with small groups during the practical hands-on sessions. As Robert pointed
|> out above, I use the debugger to get a traceback, maybe look at a variable
|> value, but then it's reading and understanding the source code again.

I seem to remember having this conversation about a year ago...

The point is, when you are interfacing to alpha/beta or even released
system/vendor software, which is not documented properly, or does not behave
as documented, and can introduce seemingly random crashes or strange behaviour,
it is sometimes only with a debugger that you can deduce what is going on.

If you write relatively self-contained software that uses system calls only
to read/write a couple of files (and allocate memory) it is much easier
to construct your software.

An example: I was dealing with OLE remoting a while back. This was alpha
software with incomplete documentation. Despite handling references correctly
in my code, some objects were not being released. It turned out the alpha
software was incrementing a reference count somewhere *internally to the
OLE code*, but not decrementing it. It was only from the debugger that I
could see that the reference count was one higher than I expected (ok,
printf could probably have done it too).

Another example: I was dealing with RPC software, and suddenly a server
starting crashing with an accvio (this was on VMS). It was only with the
debugger that I was able to find that the compiler had not initialised a
static pointer properly, so the pointer was NULL, a normally "impossible"
situation -- coming from code I had not even written (the pointer was the
RPC interface handle, which was initialised in C code generated by the IDL
compiler).

Another example: some code passes strings from Ada to C. On UNIX platforms,
this is working find. On VMS, the C code was getting bad pointers to
the strings. Only by looking at various addresses in the debugger, did
a colleague discover that the VMS Ada compiler was converting the strings
to VMS string descriptors prior to the call.

Another example: ... I could go on, but you should get the picture.

Under no circumstances are you going to find the cause of such errors
by reading and understanding your own source code.

Although I didn't make it clear at the time, this is what I meant by
needing a debugger "in the real world".

Ian