[boost] Re: Re: Re: Re: improved assertions?

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-14 22:18:21

"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:0afb01c21414$255d7b20$6601a8c0_at_boostconsulting.com...
>
> From: "Ted Byers" <r.ted.byers_at_[hidden]>
> > "David Abrahams" <david.abrahams_at_[hidden]> wrote in message
> > news:0a7a01c213f6$ff88e780$6601a8c0_at_boostconsulting.com...
> > > Example 1: assertions. By the time the stack is unwound much
> information
> > is
> > > lost. On Unix, for example, you want a core dump, not an exception. On
> > > Windows you also don't want stack unwinding, though the case is a
> little
> > > more complicated there.
> > >
> > What I would be inclined to do with assertions is collect as much
> > information as I can at the point where the assertion failed:
> presumably, a
> > clever programmer could capture this information that would be lost by
> the
> > time the stack is unwound.  I'd have to rely on someone like you to tell
> me
> > how to capture that information, and then I'd package it in one of my
> > traceable exceptions which can then give me my trace information.
>
>
> On systems where there's a built-in facility for that (Windows, Unix),
> anything you can do yourself is going to be vastly inferior to what the
> system can give you by default. On Windows you get JIT debugging, which
> invokes a debugger on the program with (if you know the right tricks) the
> entire program state preserved. On Unix, a core dump is a debuggable image
> of the program state.
>
Fair enough.  The first problem, though, is one of knowing the right tricks.
You have to know how to use the JIT debugger on Windows, and how to use a
core dump on Unix.  While you know all this stuff, I am learning it the hard
way, and haven't found useful information, at least in the references I
have, on using the JIT debugger on Windows or a core dump on Unix.  And it
is ceretain that none of my clients would have a clue about any of this.
But this gets us into debugging in two contexts: 1) the developer producing
and debugging his own code, and 2) the developer having to solve problems
his clients have encountered with his code.

But the second, problem, though, is that with traceable exceptions, and like
capability, one at least has useful information that can be dumped to a
file, and if the problem has occured on a client's machine, they can send
the file produced.  If the problem manifests itself in a binary that has
been distributed to a client, how is that client going to be able to make
use of a debugger or a core dump when they are only just barely able to turn
on their computer by themselves (an exaggeration, surely, for some clients,
but quite true for many).

It is my hope that in due course, I can find a way to more effectively a)
see what the client sees when a problem happens, and b) collect state and
trace information from the client's system on those occassions when a
problem is encountered (Ideally during an internet televideoconferencing
session with the client to discuss his experiences with the software).   No,
I don't know how to do this yet, although I suspect I'll have to use
something like ACE, and maybe even a few other libraries.

Cheers,

Ted