[mini] Enter GC Unsafe mode in handle_signal_exception #88436
Conversation
When the runtime needs to turn some kinds of signals into managed
exceptions (for example: SIGINT turns into
`new ExecutionEngineException ("Interrupted (SIGINT)")`, and some
SIGFPE turn into `DivideByZeroException`, and some SIGSEGV turn into a
`NullReferenceException`) instead of unwinding the stack from inside a
signal handler it instead adjusts the normal stack so that when the
signal handler returns, execution will resume in
`handle_signal_exception`.
That means that if the runtime was in GC Safe mode when the signal
was raised, even if the signal handler code transitions to GC Unsafe
mode, by the time the `handle_signal_exception` runs, we will have
undone the GC Unsafe transition and will be back in GC Safe.
That means if the code in `handle_signal_exception` (notably
`mono_handle_exception`) calls anything that tries to do a transition
to GC Safe, we may get an assertion.
Fixes dotnet#88405
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The thing is, for this to matter we have to be in a method that the runtime has JitInfo for (both SIGFPE and SIGSEGV handlers only call So that means we're in a wrapper and something went wrong before we called I'm not sure it's actually good to try and throw a managed exception at this point. Maybe it's better to just assert that we're un GC Unsafe mode. If we're not, something bad is going on. |
|
/azp run runtime |
|
No commit pushedDate could be found for PR 88436 in repo dotnet/runtime |
|
/azp run runtime-ioslike |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
locked as resolved and limited conversation to collaborators
When the runtime needs to turn some kinds of signals into managed exceptions (for example: SIGINT turns into
new ExecutionEngineException ("Interrupted (SIGINT)")ifMONO_DEBUG=handle-siginitis set, and some SIGFPE turn intoDivideByZeroException, and some SIGSEGV turn into aNullReferenceException) instead of unwinding the stack from inside a signal handler it instead adjusts the normal stack so that when the signal handler returns, execution will resume inhandle_signal_exception.That means that if the runtime was in GC Safe mode when the signal was raised, even if the signal handler code transitions to GC Unsafe mode, by the time the
handle_signal_exceptionruns, we will have undone the GC Unsafe transition and will be back in GC Safe.That means if the code in
handle_signal_exception(notablymono_handle_exception) calls anything that tries to do a transition to GC Safe, we may get an assertion.Fixes #88405