Re: [boost] [Backtrace] Any interest in portable stack trace?

Subject: Re: [boost] [Backtrace] Any interest in portable stack trace?
From: Andy Venikov (avenikov_at_[hidden])
Date: 2010-10-26 14:10:41

On 10/21/2010 1:10 AM, Artyom wrote:
>>
>> My  experience is that the stack is difficult to follow in debug builds
>> and close to  impossible in release builds. Highly optimized code sometimes
>> discards the  notion of a stack altogether in certain cases.
>>
>> I'm curious how you're  going to accomplish this feat and make it portable
> too?
>>
>> If you are  successful, this would definitely be a valuable tool to have.
>
> Because I'm not trying to reinvent the wheel:
>
> Linux, Solaris and Mac OS X have functions backtrace and backtrace_symbols
> in libc: See: http://linux.die.net/man/3/backtrace
>
> Windows starting from XP has RtlCaptureBackTrace in kernel32.dll:
> See http://msdn.microsoft.com/en-us/library/ff552119(VS.85).aspx
>
> So the rest is translate symbols, under Unixes I have dladdr and under Windows
> dbghelp.
>
> Of course for inlined functions or for functions with omitted frame pointer
> you'll
> not see their frame it the trace, but for rest of it, it should work.
>
> Artyom
>

This functionality would definitely be appreciated.

Beware though, that gcc folks made a controversial decision to set "no 
frame pointer" flag as a default on 64bit POSIX. That also means that 
backtrace() will be either very inefficient (in my tests it was more 
than 100x slower than when the frame pointers are included) or unstable. 
It actually crashes sometimes.

That makes backtrace() pretty much useless for the code that was 
compiled with the default flags. (which is most of the shared system 
libraries). And even if the user adds (-with-frame-pointer), the start 
of the trace might be in the system libraries, so to make backtrace() 
work in that case you have to somehow limit it only to the user's code.
Scary.

Andy.