Re: [boost] Any interest for stack_trace?

From: Pavel Antokolsky aka Zigmar (zigmar_at_[hidden])
Date: 2007-05-02 11:06:27

On 5/2/07, Michael Gopshtein <mgopshtein_at_[hidden]> wrote:
> Many responses talk about using build-in compiler's capabilities. IMHO they
> don't always help.
>
> As example, in our application we want the stack trace:
> 1) be always activated, even in release builds sent to the customers
> 2) be able to print the stack trace when exception occurs
>
> 1st is much easier using custom trace, as we don't need to compile the
> project with debug info. BTW, that "instrumentation" doesn't look so bad in
> the code, and can sometimes replace comment lines, e.g:
> TRACE_UPDATE_CONTEXT("processing request");
At least in gcc, you don't need to have an executable compiled in
debug to use backtrace(). However with optimizations turned on, inline
function might not appear on stack, of course. And omitting frame
pointer would optimization would also make the tracing impossible.

> The 2nd task is more tricky, as if you don't catch the exception in same
> function where it occurs, but somewhere down the stack, the "normal" stack
> trace is lost. In our code we keep a "history" of call stacks, and can
> always print the whole stack.
All you need to do, is collect the stack trace and the exception throw
site, not in catch site. I.e. you could make an exception class, that
will retrieve a stack trace in its constructor.
 The advantage on a native approach - is that it has zero overhead.
Otherwise you introduce fairly heavy overhead into every function
call, plus you can't get a stack entries in third-partly libs.

I'm actually working now on something even more interesting - on
implementing stacktrace with function arguments. I mostly sure,
however, it could not be ported on most platforms, because the trick
I'm trying to use - is to extract function frame description from
DWARF debug information from within the executable itself. :)

-- 
Best regards,
Zigmar