Hacker News Reader

Comment by anarazel | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com