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.