[einpoklum]

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]

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/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]

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/...