[boost] Stacktrace (was: Re: Review Manager needed for stacktrace library)

Subject: [boost] Stacktrace (was: Re: Review Manager needed for stacktrace library)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-10-25 04:23:32

On 24 Oct 2016 at 21:05, Antony Polukhin wrote:

> > I do love the idea of a portable facility to capture and/or display stack
> > traces at any desired point in a running program. Seems way overdue...
> >
> > It would be even more valuable if line number and source file information
> > were available. I recognize that you just can't get that under all
> > circumstances -- but maybe you could document the per-platform
> > circumstances in which that *could* be retrieved?
> 
> The idea is good and I'm definitely going to experiment with that for
> Windows platform and for the Linux platforms soon. But I'm afraid that
> it may lead to bigger backtraces that do not fit onto screen and are
> harder to read.

I haven't done a deep dive into Backtrace yet, I'm hoping this 
weekend. But the lack of iterators problem is one I'd already 
noticed.

I was also going to propose lazy symbolisation, so only if the user 
specifically asks for source code file or line number is 
llvm-symbolizer (or the equivalent for some platform) invoked per 
stack frame.

That implies a dependency on Boost.Process, but Boost-lite actually 
has a lightweight zero dependency embedded process manager which like 
all Boost-lite libraries is drag and drop in friendly. I was going to 
suggest embedding a copy of that.

> > If function name, source file and line number were (conditionally)
> > available, I'd like to be able to retrieve an individual entry that has
> > accessors returning each of those things -- instead of operator[] returning
> > only a std::string for function name. Perhaps the source file and line
> > number would have to be wrapped in boost::optional.
> 
> I'm writing stacktrace library as a prototype for further adoption
> into the C++ Standard (I've got big ambitions and groundless
> optimism). Additional dependency to std::optional could make the
> adoption harder.

It's also a pointless optimisation. Reliable symbolisation on some 
platforms is a very, very heavy overhead, it involves launching a 
whole new process, waiting for it to complete and parsing its output. 
A std::string for the source file name which is null until lazy 
filled is plenty.

BTW Antony are you planning for Backtrace to allow portable runtime 
*modification* of stack unwinds? Every C++ implementation has an API 
to do that in its runtime, it's just not normally exposed to the 
running program. I've been a long time advocate that it ought to be, 
mainly because of the raw undiluted untrammeled power for potential 
abuse it hands to the programmer (yes, yes, I really can handle the 
power, and no, I really really promise to not do evil ... :).

Many years ago I tried to persuade WG14 to standardise that API as 
it's generally in the major C compilers too, but they refused on the 
basis that such a facility would be horribly abused and it must not 
be encouraged. Which sounds magic to my ears.

Niall

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