The signal handler just saves the trace and then wakes up another thread which does the reporting. The signaled thread uses only <stacktrace> and mutex/cv, all signal-safe as far as I can tell.
The crashing thread might hold a lock in the memory allocator - which could either self deadlock when saving the stack trace (which certainly seems to do memory allocation and thus isn't a-signal safe), or could deadlock with the crash reporting thread which definitely allocates memory all over.
I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.
stack_trace allows you to specify a custom allocator, which would protect against a lock held in the allocator (never ran into this in the real world though).
You're right about mutex & cv in the general case though
That assumes the specified allocator actually controls all allocations - somewhat doubtful across all platforms as things like dl_iterate_phdr() IIRC allocate memory (and take locks). And there's a lot more to writing signal safe code than not calling malloc. Unless an interface documents to be signal safe you're take better of assuming it is not.
FWIW I've run into malloc self dreadlocks due to rare signals plenty of time :(. In production workloads.