Re: [boost] Stacktrace library starts review today 14th Dec

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.

https://github.com/aclements/libelfin 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/