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 solu

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.