On 12/21/16 22:43, Antony Polukhin wrote:
Hi,
* 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).
Actually, that depends on the allocator. A stack-based allocator or an allocator backed by static storage could be async-safe, making `vector` async-safe as well.
So, the solution: * Change `basic_stacktrace
` to `basic_stacktrace >` and make it's constructor async-unsafe and add additional runtime parameter for stack depth.
Why not:
template<
class Backend = default_backend,
class Allocator = std::allocator
class basic_stacktrace; ? (As noted above, the constructor can still be signal-safe with an appropriate allocator.) I suggested in my review that backend as a template parameter could be beneficial and makes more sense. Note also that the allocator is instantiated on `frame`, which is what is supposed to be the element type of the stacktrace container. If `frame` is a standard layout class with only `void*` as its data member, you could still use it with underlying APIs that take `void**` as the list of stack frames. It would require a `reinterpret_cast` inside the library to cast between `frame*` and `void**`, but in return the user's interface would be clean and operate on `frame`s instead of void pointers.
* 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)`
Yes, if that's in addition to the non-async-safe function that decodes the stacktrace in-process. Also, on Windows you might have to provide `wchar_t`-based function as well. I'm not sure if `char`-based one would be safe to use in a signal handler since narow character WinAPI perform character conversion internally.
* Provide an example with dumping callstack to a file and printing it on program restart
I would suggest an example of printing the stacktrace by a separate program. Printing the stacktrace upon restart seems like a contrived case.
My list of TODOs for the library: * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution
+many. Thanks for working on this.