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
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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk