Boost logo

Boost :

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


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
* 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

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:

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
* 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

Best regards,
Antony Polukhin

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