Signal safe demangling

[tmandry]

It would be very useful if we could use cpp_demangle in signal handlers, where allocation is not allowed, for handling things like segfaults and aborts in C++ code. This is usually achieved by printing demangled text directly to stderr.

Given that the crate requires alloc today, I assume this is not currently supported. Is adding support a possibility?

EDIT: Also see discussion in rust-lang/rust#72981 (comment)

[khuey]

It would be tough without switching to something like a pre-reserved arena that we could allocate from during the stack walk.

[tmandry]

It would be tough without switching to something like a pre-reserved arena that we could allocate from during the stack walk.

That is often what happens, but for unwinding (i.e. getting the list of PC addresses, which are easy to preallocate for). Do we also need an arena for the demangler itself?

[khuey]

I took a quick look at this. The demangler does use Box, Vec, and String, so it does need the ability to allocate. Box and Vec have configurable allocators so if an arena could be made to work through Allocator that could probably be threaded through everything in cpp_demangle, but as far as I can tell String does not yet take an Allocator.

[tmandry]

That would require reserving space for all demangled symbols at the start of the process. I'm imagining something more like an API that accepts a Write type and writes directly to that (i.e. a log file or console) instead of storing the backtrace in memory.

[khuey]

Demangling C++ symbols at a minimum requires a variable size substitution table that depends on the symbol parsed so there's no way to demangle them without obtaining memory from either a preallocated block or e.g. malloc.

[fitzgen]

I've seen people write allocators that are signal safe because they just use mmap directly. Pretty gross, but if you're already in this situation where its necessary...

In general, better to save symbols somewhere and demangle them elsewhere, outside of the signal handler.