-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poorly-documented safety assumptions in unix::stack_overflow::init
#127841
Comments
uh what? I have no idea what happened here. |
unix::stack_overflow::init
cc @cuviper I believe you were the one to add the Perhaps it couldn't be at the time, I think |
I guess you must have found commit 676b9bc to "blame" me, but I don't remember any more about that offhand. I think it's global because the decision is made once when registering the signals, but needs to affect all threads. (I won't be able to dig any more until next week at the earliest.) |
dw, I figured 4 years ago might've been too long ago to remember! |
@cuviper for reference this has mostly led to this question, because I started thinking about the ordering of when we should set |
There are two parts to our
In the Rust runtime initialization code, we attempt to install our signal handler. If there is no handler previously installed, we need to create a signal stack for every thread we spawn, so that the handler has a stack to run on (the main thread obviously can't be used, it already overflowed). If there is already a handler installed, we do not overwrite it. Thus, when we create another thread, we do and should not allocate a signal stack, as that might interfere with the code that registered the action. |
Part of the reason this code is hard to follow is that there are several I've already started cleaning this up as part of #127747 |
Relevant history:
It's not clear, to me, why the update of the
NEEDS_ALTSTACK
variable is occurring. I don't know everything there is to know about signal handlers, but I do knowWe have two fairly distinct codepaths for
make_handler
. In code we control, we only call one or the other (i.e. a constant input). They're really quite different functions. So it's not clear where the logical dependencies emerge between the two.The text was updated successfully, but these errors were encountered: