Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

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 
binaries.