-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[monovm] Assertion at object.c:657, condition `lock->done' not met #96872
Comments
Probably I messed something up in #93875 |
Oh... yea... runtime/src/mono/mono/metadata/object.c Lines 615 to 657 in cf34ef0
on line 615 we know
I'll need to try this in a debugger after all. Trying to guess what is wrong isn't working |
Just noticed another thing that is wrong. when we |
Oh. It's probably a spurious wakeup. We need to actually re-evaluate
https://man7.org/linux/man-pages/man3/pthread_cond_wait.3p.html |
Can repro the crash on a real Pixel 6a, but not in an emulator |
the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes dotnet#96872
the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes #96872
* mono_runtime_class_init_full: handle spurious wakeups the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes #96872 and #96804 * fix unbalanced handle frames if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL. Instead setup the handle frame once upfront
Reopening until the 8.0.x backport is merged |
#96905) * mono_runtime_class_init_full: handle spurious wakeups the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes #96872 and #96804 * fix unbalanced handle frames if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL. Instead setup the handle frame once upfront --------- Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
Backport has been merged, too. |
We were also able to reproduce this error with Android SDK 31, 33 and 34. |
When will the fix be released? We are all stuck by this issue. |
@liejuntao001 see #96804 (comment) servicing releases for .NET come out approximately monthly. The fix for this issue is queued up for the February servicing release.
This assertion is new in 8.0.101. What is the issue in 8.0.100? Could you open a new GitHub issue for it. |
@lambdageek as rolling back workloads is not easy (it requires rollback files), changing the active version of the SDK in global.json does not have any effect on the active workload, which can cause confusion. I hope that dotnet/designs#294 will clear a lot of this confusion...
As for the monthly servicing, February is quite far away for an issue that arises when updating visual studio, and for which rolling back is difficult. |
You're right. that would explain it.
As a temporary workaround you might be able to force the 8.0.101 SDK to use the 8.0.0 runtime pack with something like this: <Target Name="UpdateRuntimePackVersion" BeforeTargets="ProcessFrameworkReferences">
<ItemGroup>
<KnownRuntimePack Condition="%(RuntimePackLabels) == 'Mono'" LatestRuntimeFrameworkVersion="8.0.0" />
</ItemGroup>
</Target> |
This workaround works for me. |
* mono_runtime_class_init_full: handle spurious wakeups the condition variable may be signaled even if the initialization by the other thread is not done yet. Handle spurious wakeups the same way as timeouts: go around once more from the beginning. Fixes dotnet#96872 and dotnet#96804 * fix unbalanced handle frames if we goto retry_top, don't set up a new handle frame that lacks a matching HANDLE_FUNCTION_RETURN_VAL. Instead setup the handle frame once upfront
Hi, has the fix been released. i am getting crashes as well.. |
Hello, I am still experiencing this issue despite being up to date with MAUI latest version and also including the workaround in the csproj. |
I don't think the fix is released yet. These guys don't believe in hotfixes, it seems, even for critical issues like this. May have something to do with the fact that the error is so far down in the system, I dunno. We have to wait for the Februrary push. |
When is the February push out? It is February now. We're waiting. Our customers projects are crashing. |
This bug broken our production App. |
So when will this be available in MAUI? I am getting this crashes all the time |
As always, on patch Tuesday - the second Tuesday of a month - so February 13th. |
Any joy with the new update, has anyone had a chance to try it (if it's available) |
Upgrading to VS 17.9.0 fixed the issue for me 👍 |
I'm on Visual Studio for Mac 2022 they've got a new update out today so I'll try that tomorrow, I also use Rider and there's a Mono update for VS, which I think is where the issue is, fingers crossed! |
Sdk 8.0.200 fixed the issue on Debug configuration for me, but still persist in Release for android. No way |
Description
When running some threaded code in a MAUI app (android in this case), the app may fail with the following error:
runtime/src/mono/mono/metadata/object.c
Line 657 in cf34ef0
This happens when connecting in parallel to multiple websockets, see the
StartConnection()
inMainPage.xaml.cs
.Reproduction Steps
Expected behavior
The app does not crash
Actual behavior
the app crashes immediately most of the time
Regression?
Yes, was working fine in 8.0.100.
Known Workarounds
Yes, don't execute any threaded code.
Configuration
Other information
No response
The text was updated successfully, but these errors were encountered: