Re: [boost] Any interest for stack_trace?

From: Michael Gopshtein (mgopshtein_at_[hidden])
Date: 2007-05-02 11:33:39

"Pavel Antokolsky aka Zigmar" <zigmar_at_[hidden]> wrote in message 
news:b9e625b70705020806l1f5d8427ua4d7938596b89a4a_at_mail.gmail.com...
> 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.

When compiled in non-debug mode, I think that you can't get all context 
info. For example, using custom stack trace you can "change" the context in 
some locations inside the function. Besides, those "locations" can be given 
descriptive names, making it easy to understand the trace.

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

This is a good solution, I agree, and can be incorporated with "custom" 
stack trace too.

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

The overhead is no heavy, you also don't need to put trace functions at 
every place in the code, just in major functions. In our product the stack 
trace didn't cause any noticable regression in performance (and preformance 
is very important for us).

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

That could be interesting too, you can also handle cases of pointer 
parameters - by storing the data.

>
> -- 
> Best regards,
> Zigmar
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>