Not planned
Description
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...
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
DemiMarie commentedon Jul 13, 2017
Can we get the data from what the OS passes to the signal handler?
joshlf commentedon Jul 13, 2017
Would it be possible to not use the stdlib TLS mechanisms and instead implement a custom TLS access mechanism?
alexcrichton commentedon Jul 13, 2017
@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 commentedon Dec 1, 2024
Closing in favour of #133698.