[iOS][MacCatalyst] error: mono_coop_cond_broadcast Cannot transition thread from STATE_BLOCKING with DO_BLOCKING #88405
Comments
simonrozsival
added
runtime-mono
dotnet-issue-labeler
bot
added
the
needs-area-label
|
Tagging subscribers to 'os-maccatalyst': @steveisok, @akoeplinger Issue DetailsWhile working on xamarin/xamarin-macios, I experienced a crash in mono with the following stack trace when building an app in the Debug configuration: The same code works fine with I'm not sure if this is a bug in Mono or in Xamarin. It seems to be similar to #47121 and xamarin/xamarin-macios#7742. /cc @akoeplinger @ivanpovazan @rolfbjarne
|
akoeplinger
added
area-Diagnostics-mono
and removed
untriaged
|
/cc @lambdageek |
|
I think It looks like we ended up in GC Safe somehow at |
|
@simonrozsival Does this happen with net8.0-maccatalyst, too or only net7.0-maccatalyst |
|
Hmm... I think the real issue is in I'm not clear on why we think the segv is in managed code. (I would expect some kind of native-to-managed wrapper on the stack after But probably what we should do is transition to GC Unsafe in And in any case tl;dr I think |
|
@lambdageek it was .NET 8 |
|
@simonrozsival is it using the new managed registrar? |
|
@lambdageek yes, I forgot to mention that. I will try the other registrars and see if it's just the new managed registrar. |
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
ghost
added
the
in-pr
|
ok, so in that case I think one of those (I'm not sure why we would SEGV there before doing the transition) @simonrozsival I opened a PR to fix the assertion, but I'm pretty sure you're just going to start getting unhandled |
|
I'm not very confident my PR is the right fix. it might be better to assert in |
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 #88405
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
While working on xamarin/xamarin-macios, I experienced a crash in mono with the following stack trace when building an app in the Debug configuration:
The same code works fine with
/p:MtouchDebug=falseor in the Release configuration.I'm not sure if this is a bug in Mono or in Xamarin. It seems to be similar to #47121 and xamarin/xamarin-macios#7742.
/cc @akoeplinger @ivanpovazan @rolfbjarne
The text was updated successfully, but these errors were encountered: