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

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-20 11:02:01

> > > >       On Unix, for example, you want a core dump, not an exception.
> > >
> > >   I didn't do much Unix programming, but I commonly
> > >   don't want my apps to core dump at a customer's.
> >
> > You don't want it to assert either. The information in a core dump is
more
> > useful to you and the customer than a call stack description, and no
more
> > confusing.
>
Actually, I don't want a core dump either, or, perhaps I should say, I won't
until someone shows me how to extract the required information from it in a
way that a mere mortal can understand.

I tried the JIT debugger provided on Windows (actually it looks like the JIT
debugger provided, in one instance, by MSVC++, and in another instance, by
Borland's C++ Builder).  I could not make sense of anything I saw in it
because all I saw was what looked like assembler (because it looked alot
like the assembler I have seen in some of my books that use inline
assembler) in one window, and some other stuff that I did not recognise.
For any of that to be useful to me, it has to be turned into a form that I
can understand.

It does me no good, even if the JIT debugger on Windows, or the core dump on
Unix, contain more information than I can obtain from my traceable
exceptions if I can't extract the information in a form I can understand.

And there is the question of the correctness of the information.  I am
facing right now a situation where, looking at the call stack trace window
in Borland's debugger, the information is correct up to the statement that
produces an access violation.  But once the access violation occurs, the
information in the window disappears momentarily, and when it reappears it
is wrong, excluding a couple functions that HAD been called and including a
couple functions that had NOT been called.  This is something I am certain
of because I was stepping through the code at the time, and making a point
of stepping into each and every function, whether my own or part of the
standard C++ library.

>
> > [...]
> > > > Example 2: memory allocation tracking and leak detection. An
extremely
> > > > useful technique involves labeling each allocated block with the
call
> > stack
> > > > leading to the allocation. If every allocation causes an exception,
> > your
> > > > program won't get far.
> > >
> > >   You mean, "if every allocation causes an exception
> > >   instead of a core dump"? Why is that a problem if
> > >   you can get the stack from the exception's ctor?
> >
> > No, I mean that allocation requests are supposed to return a memory
block
> > unless memory is exhausted. If you have to throw an exception to get the
> > stack trace, you can't return the memory block.
>
>   That seems to be a misunderstanding. I don't think
>   exception should be thrown merely to get a call stack.

Yes, this IS a misunderstanding.  I think it foolish to throw an exception
just to get a call stack.  If we need a trace in the absense of an error,
then I'd want a function I can call that will give it to me.  I just do not
know how to write such a function, at present anyway.

>   But I thought we were discussing the usefulness of
>   intrusive/non-intrusive stack tracing in the case of
>   an exception.
>
Yes, this is exactly what we're talking about.  This is the sort of thing
that Neal says provided the initial motivation for asking the question in
the first place.

>   Well, of course, once you have a portable/ported way
>   to get a call stack from any point of the program,
>   using this in the exceptions ctor would make a lot of
>   sense. I just never attempted to do this even across
>   the few platforms we program for.
>
Agreed, but how do you write such a function?  I don't know this.

But, gotta run (Mom's expecting me for lunch, and I'm late: might get
grounded ;-)

Cheers,

Ted