Boost logo

Boost :

From: Hendrik Schober (boost_at_[hidden])
Date: 2002-06-20 06:12:32


"David Abrahams" <david.abrahams_at_[hidden]> wrote:
> [...]
> > You can capture the stack in the exception's ctor.
>
> ...and the values of all local variables, in a useful way? What about the
> state of objects whose destructors run during unwinding?

  Mhmm. I understand that Unix core dumps provide this
  "post mortem". Since the platform I work on doesn't
  have this, for me so far there were two possibilities:

  Either I'm debugging the app, then I always have a
  breakpoint in my exception base class' ctor and can
  see the stack with all local variables etc. from it.
 
  Or the app is running at a customers. Then, for the
  reasons given earlier, I usually want to avoid to have
  my code abort. Then, my (intrusively) collected
  exception stack info, together with the logging output,
  is a really great improvement over an "abnormal program
  termination" message, which my system gives me.

> > > 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.

  I don't think it is more useful for the customer,
  since are core dump usually also means that they
  lost their work.
  As I've said before, customers calling in because
  they've lost hours of work when the printer driver
  blew it while they were doing a test print will
  not raise my reputation in the support department.

> [...]
> > > 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.
  But I thought we were discussing the usefulness of
  intrusive/non-intrusive stack tracing in the case of
  an exception.

  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.

> -Dave

  Schobi


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk