Hacker News Reader

Comment by anarazel | Hacker News Reader

This does not even remotely look to be signal safe to me?

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.

> I also quite doubt that std::mutex, and even more so std::condition_variable are guaranteed to be signal safe.

They are not. Use sem_t for signaling.

edit: also even if they where, the signal handler might wait forever for a mutex owned by the blocked thread.

It was more a rethorical doubting because I did not want to look the standard up on my phone....

Reply on news.ycombinator.com