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

From: scleary_at_[hidden]
Date: 2002-06-12 16:26:37

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

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