Boost logo

Boost :

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

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.


ned Productions Limited Consulting

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