[release/9.0.1xx] [src/runtime] Don't allow native code to resolve a weak reference for an object in the finalizer queue. #23086
Conversation
… an object in the finalizer queue.
The following happens:
1. An instance of a custom NSObject subclass is created, with both a native instance
and the corresponding managed wrapper.
2. Native code creates a weak reference to the native instance.
3. No other managed code references the managed instance, and there's no non-weak
native reference to the native instance, so the GC schedules the managed instance
for finalization.
4. Native code fetches the native instance from the weak reference.
5. Native code thinks it can do whatever it wants with the native instance, because
it got a perfectly valid (and retained) native instance. Unfortunately, there's no way
to stop the managed instance from being finalized (which happens on a background
thread anyway, so there's no thread-safe way to do it), which means havoc ensues.
The most frequent manifestation of this problem has been like this:
ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x13d566800 (type: Microsoft_Maui_Platform_MauiTextField). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'Microsoft.Maui.Platform.MauiTextField' does not have a constructor that takes one NativeHandle argument).
at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution )
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr , IntPtr , MissingCtorResolution )
at ObjCRuntime.Runtime.GetNSObject(IntPtr , MissingCtorResolution , Boolean )
at ObjCRuntime.Runtime.GetNSObject(IntPtr )
at ObjCRuntime.Runtime.InvokeConformsToProtocol(IntPtr , IntPtr )
at ObjCRuntime.Runtime.invoke_conforms_to_protocol(IntPtr obj, IntPtr protocol, IntPtr* exception_gchandle)
Exception_EndOfInnerExceptionStack
but other problems can also occur.
This is a rather complicated issue to fix, because:
* There's no way to be notified when native code creates a weak reference to a
native instance.
* There's not even a way to know if anybody has a weak reference to a native
instance.
* I also looked into manually clearing the weak references for a native
instance, but that's not possible either.
However, it is possible to basically say "nope!" when native code tries to
fetch a native instance from a weak reference:
We override the '[NSObject retainWeakReference]' method for all custom
NSObject subclasses, and return FALSE if the corresponding managed object has
been scheduled for finalization (otherwise call the base class implementation).
The ['[NSObject retainWeakReference]'][1] method is public, but it's not
documented how it's supposed to behave. Fortunately, the corresponding [source
code][2] is public, so we can figure out the semantics ourselves: return
`TRUE` if the object can be / was retained, `FALSE` otherwise.
* Fixes #21648.
* Fixes dotnet/maui#21485.
* Fixes #19076.
Might also fix the following issues:
* #22867
* #19579
* #4207
* https://bugzilla.xamarin.com/show_bug.cgi?id=34242 (https://web.archive.org/web/20170630214134/https://bugzilla.xamarin.com/show_bug.cgi?id=34242)
[1]: https://developer.apple.com/documentation/foundation/nsproxy/retainweakreference
[2]: https://github.com/apple-oss-distributions/objc4/blob/f126469408dc82bd3f327217ae678fd0e6e3b37c/runtime/NSObject.mm#L539-L541
✅ [CI Build #b4e4349] Build passed (Build packages) ✅Pipeline on Agent |
✅ [PR Build #b4e4349] Build passed (Detect API changes) ✅Pipeline on Agent |
✅ API diff for current PR / commit.NET ( No breaking changes )✅ API diff vs stable.NET ( No breaking changes )ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
✅ [CI Build #b4e4349] Build passed (Build macOS tests) ✅Pipeline on Agent |
💻 [CI Build #b4e4349] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
💻 [CI Build #b4e4349] Tests on macOS M1 - Mac Monterey (12) passed 💻✅ All tests on macOS M1 - Mac Monterey (12) passed. Pipeline on Agent |
💻 [CI Build #b4e4349] Tests on macOS arm64 - Mac Sequoia (15) passed 💻✅ All tests on macOS arm64 - Mac Sequoia (15) passed. Pipeline on Agent |
💻 [CI Build #b4e4349] Tests on macOS M1 - Mac Ventura (13) passed 💻✅ All tests on macOS M1 - Mac Ventura (13) passed. Pipeline on Agent |
🚀 [CI Build #b4e4349] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 115 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
rolfbjarne
deleted the
dev/rolf/backport-pr-23072-release/9.0.1xx-2025-06-19
branch
|
@rolfbjarne Hi Rolf, thanks for looking into this. Do you know when this fix will be released? :) |
This fix will be included in our next service release, which is scheduled to come out soon (unfortunately I can't be more specific). |
|
may I ask a possibly stupid question? :-S If the label says "9.0.1xx" does this mean that it will be in a Maui-Release with version-number "9.0.100" or greater? I'm still trying to understand / learn about the version-numbers of MAUI, .Net, SDK, … :D And: Is there any workaround available until then? I see this crash happen rather frequently with our app that I just upgraded to .net9 and now I have a problem because I cannot ship it in this state ... what can I do? |
|
I have the same question- how can we check if this was included in the latest release from July 8th? |
No, the bug is in the iOS workload, not MAUI, so the fix will be in the iOS workload.
It's included. It's mentioned in the release notes: https://github.com/dotnet/macios/releases/tag/dotnet-9.0.1xx-xcode16.4-9207 |
|
Pardon me for an urgent question:
Edit: Edit 2: and even if this one was disposed in the "Disposed" override, something went wrong at some point … … maybe it clicks and you say: "oh, wait, maybe there's a thing we need to fix" … or maybe you say: "sorry, but without a repro I cannot do anything" :D Or maybe even: "oh wait, no, such observer doesn't work anymore with maui - you need(!) to make it into a handler now" … Question is:Are there known problems with .net9 / maui on iOS Versions older than iOS 18 (or maybe older than iOS 17)? It doesn't happen alle the time but rather often. And it happens almost everywhere in the App so it's not some specific function / code in my own CodeBehind or Classes Any idea? Is the Crashlog helpful? and no, I'm pretty sure I'm not able to create a small sample project :( as I don't know what causes this in the first place I have this fix installed:Crash log TestFlightI was able to get a crash-log via TestFlight that looks like this (the crashed thread) Viewed in XcodeIn Xcode I can see a bit more for the addresses of my App: |
6 participants
The following happens:
An instance of a custom NSObject subclass is created, with both a native instance
and the corresponding managed wrapper.
Native code creates a weak reference to the native instance.
No other managed code references the managed instance, and there's no non-weak
native reference to the native instance, so the GC schedules the managed instance
for finalization.
Native code fetches the native instance from the weak reference.
Native code thinks it can do whatever it wants with the native instance, because
it got a perfectly valid (and retained) native instance. Unfortunately, there's no way
to stop the managed instance from being finalized (which happens on a background
thread anyway, so there's no thread-safe way to do it), which means havoc ensues.
The most frequent manifestation of this problem has been like this:
but other problems can also occur.
This is a rather complicated issue to fix, because:
native instance.
instance.
instance, but that's not possible either.
However, it is possible to basically say "nope!" when native code tries to
fetch a native instance from a weak reference:
We override the '[NSObject retainWeakReference]' method for all custom
NSObject subclasses, and return FALSE if the corresponding managed object has
been scheduled for finalization (otherwise call the base class implementation).
The '[NSObject retainWeakReference]' method is public, but it's not
documented how it's supposed to behave. Fortunately, the corresponding source
code is public, so we can figure out the semantics ourselves: return
TRUEif the object can be / was retained,FALSEotherwise.Might also fix the following issues:
Backport of #23072.