Random crashes with "Could not find an existing managed instance for this object, nor was it possible to create a new managed instance"

[formerlymisterhenson]

Apple platform

iOS

Framework version

net9.0-*

Affected platform version

VS 2022 17.12

Description

We have received feedback from users experiencing random crashes in our app, which have led to some instances of data loss. The app, used for creating and managing health records, is encountering issues with "marshaling Objective-C objects" like MauiTextField and ContentView.

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

Error: System.Exception: CurrentDomainOnUnhandledException
 ---> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x156f97480 (type: Microsoft_Maui_Platform_ContentView). 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.ContentView' does not have a constructor that takes one NativeHandle argument).
   at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
   at ObjCRuntime.Runtime.ConstructNSObject[UIResponder](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
   at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle , Boolean )
   at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr , IntPtr , RuntimeMethodHandle )
   at ObjCRuntime.Runtime.GetNSObject[UIResponder](IntPtr )
   at UIKit.UIResponder.get_NextResponder()
   at Microsoft.Maui.Platform.ViewExtensions.FindResponder[UIScrollView](UIView view)
   at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.AnimateHidingKeyboard()
   at ObjCRuntime.Trampolines.SDAction.Invoke(IntPtr block)
   at UIKit.UIView.AnimateNotify(Double , Double , UIViewAnimationOptions , Action , UICompletionHandler )
   at UIKit.UIView.Animate(Double , Double , UIViewAnimationOptions , Action , Action )
   at Microsoft.Maui.Platform.KeyboardAutoManagerScroll.WillHideKeyboard(NSNotification notification)
   at Foundation.InternalNSNotificationHandler.Post(NSNotification s)
   at Foundation.InternalNSNotificationHandler.__Registrar_Callbacks__.callback_1514_Foundation_InternalNSNotificationHandler_Post(IntPtr pobj, IntPtr sel, IntPtr p0, IntPtr* exception_gchandle)
   Exception_EndOfInnerExceptionStack

Steps to Reproduce

Unfortunately, we are unable to provide specific steps to reproduce the issue, as the crashes appear to occur randomly. The issue seems to be related to "marshaling Objective-C objects" like MauiTextField and ContentView, but there is no consistent pattern or specific actions that reliably trigger the error. We are continuing to monitor the situation and gather more information in hopes of identifying any potential triggers. Based on the nature of the issue, we believe it may be related to xamarin-macios. We don't think this happens on Windows, but as dotnet/maui#21485 exists, we are not that sure about this.

Did you find any workaround?

No 😔

Relevant logs

No response

[rolfbjarne]

These issues can be rather difficult to track down, and it's imperative to be able to reproduce them, otherwise we'll just be guessing.

However, there's one thing you can do to try to trigger them: run the GC aggressively.

Something like this should do it:

static void Main (string[] arguments)
{
	var thread = new Thread (() => {
		while (true) {
			Thread.Sleep (5000);
			GC.Collect ();
		}
	});
	thread.IsBackground = true;
	thread.Start ();

	// ...
    UIApplication.Main(args, null, typeof(AppDelegate));
}

This is obviously not meant to be shipped, but running with this during development will often make the problems you're experiencing easier to reproduce.

Can you try this and see if you have any luck?

[formerlymisterhenson]

Thanks again for your suggestion to aggressively trigger the GC to help reproduce the crashes. Interestingly, we had similar GC.Collect() code in place previously, as part of our attempts to address memory-related issues. This was a temporary, desperate measure to mitigate memory related crashes we were encountering, but it wasn’t a long-term solution. (We also had some temporary teardown code in place, similar to the approach used in the so called "MemoryToolkit". However, that code has since been removed as well.)

Since your suggestion, we've removed the GC.Collect() code entirely in our most recent release (as of last week). Unfortunately, we're still seeing random crashes, but the key difference is that we no longer have any log output. This leads us to suspect that iOS might be terminating the app due to memory pressure, rather than an issue directly related to GC.

We’re continuing to monitor the situation and try to gather more data. Given that the crashes seem random and aren’t easily reproducible.

[formerlymisterhenson]

Just to vent a little... The ticket is closed now, and of course, we can’t reopen it after 7 days. We've spent so much time profiling and troubleshooting this issue, dealing with memory management problems that have been around since Xamarin.Forms. It feels like we've been fighting memory leaks for ages, and now we're just left hanging without any way to follow up. Honestly, it's frustrating not being able to continue the conversation or get the support we need.

[rolfbjarne]

Just to vent a little... The ticket is closed now, and of course, we can’t reopen it after 7 days. We've spent so much time profiling and troubleshooting this issue, dealing with memory management problems that have been around since Xamarin.Forms. It feels like we've been fighting memory leaks for ages, and now we're just left hanging without any way to follow up. Honestly, it's frustrating not being able to continue the conversation or get the support we need.

I'm sorry to hear about your struggles, and we're here to help.

We can always reopen issues, so feel free to open a new issue if you can't reopen an issue yourself, we're happy to do that for you.

[rolfbjarne]

Since your suggestion, we've removed the GC.Collect() code entirely in our most recent release (as of last week). Unfortunately, we're still seeing random crashes, but the key difference is that we no longer have any log output.

Note that the GC.Collect code shouldn't make a crash app (or fix any crashes [1]) - it's purpose is to trigger any crashes more reliably during development, which would hopefully make them easier to diagnose and fix (instead of hearing about the app crashing for your customers, and not being able to reproduce yourself).

[1]: the one exception here is that GC.Collect may keep your app's memory usage lower, thus preventing the OS from terminating the app if it uses a lot of memory. Note that if there are memory leaks, the app will likely crash sooner or later anyway, the GC.Collect will just delay it.

[formerlymisterhenson]

Thank you for taking the time to respond - I really appreciate it and feel honored, especially since I’ve read many of your responses and blogs over the years. Apologies if my earlier comment came off unconstructive; it’s just been a tough issue to tackle.

We’ve been trying to follow best practices as much as possible, like using static event handlers instead of anonymous, implementing INotifyPropertyChanged properly, and keeping object lifetimes in check with DI and so on. That said, I haven’t dived too deeply into profiling snapshots yet - it’s quite complex for me to fully grasp.

One thing I’ve been wondering: could this issue stem from how the Mono GC and native iOS GC might be interacting? For instance, is it possible that objects are being collected too early as it doesn't makes much sense to me, iOS (?) tries to instantiate a new managed instance. Or might it work if I tried using custom handlers and try to introduce such constructor myself?!

I completely understand how important it is to have a reproduction sample, and I’d genuinely love to provide one. Unfortunately, our corporate app has grown significantly in complexity, and with the ongoing pressure of the project, creating a simplified example hasn’t been feasible. That said, we even brought in freelance “specialists” to help diagnose and address these memory-related challenges, but unfortunately, they weren’t able to offer any better solutions, which has been discouraging.

Well, I don’t know... this really sucks as a bug report, to be honest. I’ve probably used enough ChatGPT energy to power a small city for a year just trying to figure out how to frame this properly. Maybe this is turning into more of a discussion than a report at this point?

I have to admit, I’m feeling a bit desperate at this point, but I really appreciate all the help and insights you’ve provided so far. I’m truly grateful for any further suggestions you might have that could help me work through this. Thanks again for your time, support, and guidance - it's really appreciated!

[formerlymisterhenson]

PS: The app's complexity stems from several factors. It includes dozens of pages with intricate logic, and an ERP-like approach that stores form definitions in the database. Each form can contain 200+ controls, adding to the challenge of managing data and rendering. Users can upload multiple photos, resulting in terabytes of data. The app also relies on third-party libraries like Syncfusion. Additionally, background threads are used for tasks like data/image uploads (to sync local "offline" data with the server) and data processing, requiring careful management of thread safety and performance.