Re: [boost] Stack tracing (was: improved assertions?)

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-12 17:06:14

----- Original Message -----
From: <scleary_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 12, 2002 6:26 PM
Subject: RE: [boost] Stack tracing (was: improved assertions?)

> > FWIW, Ted Byers is working on this for BCB too, as you can see on  the
> > borland forums.
>
> The approach taken by Ted Byers, described in "Tracing Exceptions with an
> Exception Stack" (Richard Nies, CUJ Apr 2002) is a totally different
> approach than what has been described so far:
>
Yes, I noticed this after I post that.

> What the StackWalk API will allow is the actual walking of the CPU call
> stack, which gives us at least the addresses of the call stack.  The
> Nies/Byers approach is dependent on *manually* adding "stack" information.
> They do this by pushing the stack information onto an exception object as
it
> is re-thrown from one catch-handler to another.  The main drawback to this
> approach, IMO, is that it forces every function that wants to be included
in
> the stack dump to have a try...catch that manually adds its own stack
> information.  Here's the quote from the end of the CUJ article: "Traceable
> exceptions are most effective when the software trace coverage is
maximized.
> Towards this goal, every possible method should minimally have a default
> outer try/catch block with a 'CommonExcep' catch clause that invokes the
> 'push' method."
>
> The StackWalk (and other platform) APIs work differently: they walk down
the
> stack, and then various means are used to look up the symbol (i.e.,
function
> name) corresponding to the stack addresses.  On Win32, the procedure is:
>   Convert the virtual (32-bit number) address to a logical address
(module,
> section, offset triplet)
>   Use the logical address to look up a symbol name in a map file
>
> However, there are several restrictions and strange behavior that I have
> bumped into getting this to work with Borland:
>   Sometimes the virtual -> logical translation fails (for some system
> modules) -- in this case, I just output the virtual address
>   The stack can only be walked in specific conditions -- e.g., from a
filter
> expression of a structured exception handler
>   While walking the stack, only limited functions can be called --
> specifically, new & delete don't seem to work quite right (sometimes they
> do, sometimes not...) -- but I've gotten it to work by allocating memory
> from a designated heap (not the default heap).
>
> The memory-related problems have caused me more concern than the others; I
> currently only use the stack-tracing code for dumping out just before
> program exit (e.g., access violations).  I'm not 100% sure that dynamic
> allocation is suppored in this fashion by Win32...
>
> -Steve
>
OK.
I invited Ted to join here.

It seems to me that we are facing two different solutions to a quite similar
problem:

a) automatically trace back the stack with as much symbolic information as
possible, requiring use code only at the catch point.
b) manually collect context information while exceptions are unwinding the
stack, requiring a lot of user intervention.

a) seems clearly the best solution from a user POV, but it also seems the
most harder to achieve.
b) seems to be a lot more cumbersome from a user POV, but it also seems
feasible on the short time.

I think we should start by considering which option do we want.

I lean towards (b) until I see some indication that (a) is really possible
for the popular platforms.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com