[boost] Stacktrace review: concern, probable solution and review news

Subject: [boost] Stacktrace review: concern, probable solution and review news
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-21 14:43:04

Hi,

The biggest concern with the stacktrace library is it's usability in
async-signal-handlers. Here are some facts:
* users definitely want to use the library in async-signal-handlers to
print stacktraces on SIGSEGV/SIGBUS/SIGABRT
* the only cross-platform async-signal-safe thing that can be done -
is to print function addresses (without names and source line
locations)
* reviewers wish to have a smaller size of the `stacktrace` class,
want to avoid template parameter and have a std::vector<frames> like
interface (this is async unsafe because  vector does dynamic
allocations).

So, the solution:
* Change `basic_stacktrace<size_t>` to `basic_stacktrace<class
Allocator = std::allocator<void*>>` and make it's constructor
async-unsafe and add additional runtime parameter for stack depth.
* Provide async-safe functions that dump addresses separated by
whitespace (format also acceptable by addr2line and atos):
    * `void dump_stacktrace(int fd)`
    * `void dump_stacktrace(HANDLE fd)`
    * `void dump_stacktrace(const char* filename)`
* Provide an example with dumping callstack to a file and printing it
on program restart

Does it seem reasonable? Does it satisfy your needs?

Review news:
* User named LogicalKnight tested the library on MacOS and it works
well. A few issues in examples must be fixed:
https://github.com/apolukhin/stacktrace/issues/10

My list of TODOs for the library:
* Fix the async unsafe code in signal catching example
* ? Provide a low-level API for getting stacktrace as array of void pointers
* MinGW fails to compile, because of missing "Dbgeng.h" headers. This
must be fixed by manyally forward declaring required functions using
the boost.winapi way.
* Add a note about the Boost.Exception usage to the example with
embedding stack into exception.
* Take a look at the llvm-symbolizer, atos and libdwraf; try hard to
produce a non-forking solution
* ? Deserialization/inspection of stacktrace on other machine
* BOOST_NOINLINE inline trick to avoid printing internals in the
stacktrace + fix Intel warnings
* At github one of the users was complaining about the performance of
ostreaming operations. There is a way to significantly speedup
ostreaming without changing the interface of the library. I'll do the
optimization after the Boost Review.
* Improve docs for the "Build, Macros and Backends" sections (say that
library is using system headers, no 3rd party libraries must be
installed or manually linked; backtrace() is LINUX specific, not
POSIX)
* Add a note to the docs that library is header only by default and
usable in C++98/C++03.

Things NOT to do ever:
* Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those
ideas are out of the library scope
* Callbacks to do things on stacktraces - no way to satisfy all the
needs and make them optimal on all the platforms. Do some caching
instead

-- 
Best regards,
Antony Polukhin