From: Atry (pop.atry_at_[hidden])
Date: 2007-05-02 11:21:32
Pavel Antokolsky aka Zigmar wrote:
> 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. :)
Is it something like va_start/va_end?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk