3 ms·

What is async-unsafe in using `<stacktrace>`? As for not using standard allocators - not a problem, just have a fixed area set aside as a buffer for crash repo

What is async-unsafe in using `<stacktrace>`? As for not using standard allocators - not a problem, just have a fixed area set aside as a buffer for crash reporting. Yes, it might not fit an extremely long report, but it's not that much of an issue.

catiopatio 3y ago
It’s not guaranteed to be async-safe. From the C++ proposal (P0881R7): > Note about signal safety: this proposal does not attempt to provide a signal-safe solution for capturing and decoding stacktraces. Such functionality currently is not implementable on some of the popular platforms. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0881r7.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p08... [edit] Replying here, because HN is doing its occasional obnoxious rate-limiting of replies: Signal-safe and async-safe are effectively the same thing, and “async-safe” absolutely isn’t the same thing as “thread-safe”. A code path that acquires a mutex can be thread-safe; that’s absolutely not async-safe. If boost implemented a fully async-safe stack unwinder, complete with DWARF expression support, Apple compact unwind encoding support, and all the other features required across platforms, then good for them — but that’s not what <stacktrace> is guaranteed to provide, and such a thing is still not sufficient to implement anything but the most barebones portion of a real crash reporter.
- einpoklum 3y ago
  1. signal-safe and async-safe/thread-safe is not quite the same thing, but fair enough. 2. The boost::stacktrace library (on which the standardization was mostly based IIANM) has a `safe_dump_to()` function for these cases. See here: https://github.com/boostorg/stacktrace/blob/develop/include/boost/stacktrace/safe_dump_to.hpp#L81 https://github.com/boostorg/stacktrace/blob/develop/include/...

catiopatio 3y ago

It’s not guaranteed to be async-safe. From the C++ proposal (P0881R7): > Note about signal safety: this proposal does not attempt to provide a signal-safe solution for capturing and decoding stacktraces. Such functionality currently is not implementable on some of the popular platforms. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0881r7.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p08... [edit] Replying here, because HN is doing its occasional obnoxious rate-limiting of replies: Signal-safe and async-safe are effectively the same thing, and “async-safe” absolutely isn’t the same thing as “thread-safe”. A code path that acquires a mutex can be thread-safe; that’s absolutely not async-safe. If boost implemented a fully async-safe stack unwinder, complete with DWARF expression support, Apple compact unwind encoding support, and all the other features required across platforms, then good for them — but that’s not what <stacktrace> is guaranteed to provide, and such a thing is still not sufficient to implement anything but the most barebones portion of a real crash reporter.

einpoklum 3y ago
1. signal-safe and async-safe/thread-safe is not quite the same thing, but fair enough. 2. The boost::stacktrace library (on which the standardization was mostly based IIANM) has a `safe_dump_to()` function for these cases. See here: https://github.com/boostorg/stacktrace/blob/develop/include/boost/stacktrace/safe_dump_to.hpp#L81 https://github.com/boostorg/stacktrace/blob/develop/include/...