Boost logo

Boost :

Subject: Re: [boost] Stacktrace library starts review today 14th Dec
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-12-18 08:56:00

On 18 Dec 2016 at 0:01, Andrey Semashev wrote:

> I've given it some more thought after I wrote the review, and it
> occurred to me that the main reason for the current implementation of
> `basic_stacktrace` as an array is probably the intention to allow its
> use in signal handlers. For some reason it didn't occur to me while I
> was writing the review. That is a fair goal, although I'm having a
> hard time thinking of what can be done with a stacktrace from a signal
> handler. I guess, the only thing that can be done is dumping it into a
> file, but the library does not provide such a facility (the
> `operator<<` is not suitable for this).

In the past I've parsed the backtrace to figure out what call
sequence led to the fault causing the signal handler and taken action
based on that. In case you're interested, it was a capability based
security model where the stacktrace signature was used to cache what
capabilities the calling code had. On first time seeing a stacktrace
signature, you needed to dig down the stacktrace and figure out what
perms it had based on what had called what. You might think thread
local data would be a lot easier, but a thread can overwrite its data
to fake its security context. Faking a stack backtrace is
considerably harder.

There are other applications for parsing a backtrace in a signal
handler too. They are fairly niche I suppose, but I've used the
technique a few times in my career and more than I've ever used
virtual inheritance, so it's not a never used technique.

> > * addr2line and forking is not nice. Is linking with a GPL licensed
> > code an acceptable alternative?
> I think it would be difficult to get it accepted, but probably
> possible if it's a separate header, on which nothing from the rest of
> the library depends. Of course, the most preferable solution is to
> have the whole library licensed under BSL.
> Maybe there is a different implementation of the functionality
> provided by addr2line? Niall mentioned a tool from LLVM, maybe its
> code can be reused (and I'm assuming it's licensed under BSD).

Unfortunately the LLVM library is extensive and extracting just the
code you need to do DWARF table lookups is non-trivial. addr2line
uses a LGPL libdwarf library, again non trivial to extract just what
you need which is a tiny subset of a DWARF utility library.

Many years ago to work around async safety and back when DbgHelp.dll
had two, totally incompatible versions and each user's system could
have either, I found a superb COFF and DWARF parsing library written
by some Russian guy which was malloc-free and async-safe and made
looking up a source file and line number really easy. I tried finding
it again for Antony last month, but after 20 minutes I gave up. I
last used that library maybe a decade ago.

It actually wouldn't be too much work to write your own DWARF parser
to extract source file and line number. The DWARF spec is well
documented, and it's basically just five levels of searching tables
and jumping down to the next layer if memory serves. One could write
such a parser without too much work, but most of the effort would
actually go on debugging it. After all, it would need to cope with
stripped symbols, non-Intel symbols, big endian vs little endian,
weird symbols generated by bugs in a particular compiler version and
so on. could chop some time off
development, or you could just go ahead and embed a copy as a git
subrepo as it's MIT licence.


ned Productions Limited Consulting

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