Boost logo

Boost :

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:
> Windows starting from XP has RtlCaptureBackTrace in kernel32.dll:
> See
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at