Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-21 04:02:33

On 12/20/16 01:11, Niall Douglas wrote:
> Back to Stacktrace. I think I am beginning to see a consensus emerge:
> that Stacktrace should be able to serialise the stacktrace of an
> about to be terminated process to disc in an async-safe way in a
> format which other tooling such as addr2line or llvm-symbolizer can
> consume in combination with the debug symbols to produce an accurate
> source and line number stacktrace. Stacktrace does not need to parse
> the stacktrace in an async-safe way.
> Is this consensus acceptable to the Boost community?

Sorry for repeating myself, but in my review and several replies in the
discussion I suggested that the library should provide two interfaces
for decoding a stacktrace. One for use in normal context, outside signal
handler, and the other for signal handlers. The latter has to be
signal-safe and can fork the process and reuse the former interface
internally. It could also be used to save the decoded stacktrace to a
file. This approach would allow to obtain decoded stacktrace in every
context of a program.

What you describe is quite different. It doesn't allow to decode the
stacktrace in a live process, but provides a way to obtain it
postmortem. I'm not sure how useful that would be, given that it's
already possible to produce a core dump and examine that.

In my practice though I prefer decoded stacktraces to core dumps because
it doesn't require me to have the exact same binaries on my system as
those on the client's. That is most likely not limited with binaries
shipped with my application. If I was developing a crash handler with
Stacktrace, I would prefer it produce a decoded backtrace instead of
intermediate output that needs further resolving using the involved

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