TLS accesses aren't async-signal-safe

[alexcrichton]

On many Unix platforms we install a signal handler for SIGSEGV/SIGBUS to catch stack overflow. This starts off by accessing the thread-local stack guard which in turn will access a thread_local!. Unfortunately, though, thread_local! is not async-signal-safe due to a number of reasons:

• The with function can panic.
• We might register destructors which on some platforms can allocate.
• We can allocate on other code paths.
• We can create other OS pthread keys which I don't believe is an async-signal-safe function.

Unfortunately I don't really know the best way to solve this...

[DemiMarie]

Can we get the data from what the OS passes to the signal handler?

[joshlf]

Would it be possible to not use the stdlib TLS mechanisms and instead implement a custom TLS access mechanism?

[alexcrichton]

@DemiMarie oh the problem is that we currently use two thread-local pieces of information in the signal handler: the thread's name and the thread's guard page. We use the latter for determining whether we should print anything at all and the former for a nicer error message. Unfortunately the OS doesn't pass either of these to the signal handler, but we do currently extract the segfaulting address from the signal handler.

@joshlf AFAIK APIs like pthread_getspecific aren't async-signal safe, and even if #[thread_local] is async-signal-safe it's not available on all platforms we have this implemented for.

[joboet]

Closing in favour of #133698.