[net9] System.Private.CoreLib occurs InvalidOperationException and InvalidCastException

[sleushunou]

Description

reproduces absolutely randomly both in debug and in release mode, appeared after switching from net8-ios to net9-ios (It doesn't seem like it applies to iOS)

stacktrace of InvalidCastException:

System.InvalidCastException: Specified cast is not valid.
at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
at System.Threading.Tasks.Task.FinishContinuations()
at System.Threading.Tasks.Task.FinishStageThree()
at System.Threading.Tasks.Task.FinishStageTwo()
at System.Threading.Tasks.Task.FinishSlow(Boolean userDelegateExecute)
at System.Threading.Tasks.Task.Finish(Boolean userDelegateExecute)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
at System.Threading.Tasks.Task.ExecuteEntryUnsafe(Thread threadPoolThread)
at System.Threading.Tasks.Task.ExecuteFromThreadPool(Thread threadPoolThread)
at System.Threading.ThreadPoolWorkQueue.DispatchItemWithAutoreleasePool(Object workItem, Thread currentThread)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
at System.Threading.Thread.StartCallback()

stacktrace of InvalidOperationException (from Sentry):

System.InvalidOperationException: Arg_InvalidOperationException
?, in void ManualResetValueTaskSourceCore.SignalCompletion()
?, in void ManualResetValueTaskSourceCore.SetResult(long)
?, in void ThreadPoolValueTaskSource.ExecuteInternal()
?, in void ThreadPoolValueTaskSource.System.Threading.IThreadPoolWorkItem.Execute()
?, in void ThreadPoolWorkQueue.DispatchItemWithAutoreleasePool(object, Thread)
?, in bool ThreadPoolWorkQueue.Dispatch()
?, in void WorkerThread.WorkerThreadStart()

also screenshot from debug session (from AppDomain.CurrentDomain.UnhandledException):

Reproduction Steps

have not steps

Expected behavior

no crashes

Actual behavior

crash occurs

Regression?

works in net8-ios

Known Workarounds

No response

Configuration

net9, ios 18

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[TDiblik]

hey, i would love to look into this, could you please provide a minimal reproducible example?

[sleushunou]

so far it's very difficult for me to understand where this is being reproduced: the project is very large, the stack trace is absolutely uninformative for me

[sleushunou]

perhaps you can find breaking changes that occurred during the transition from net8 to net9 based on the stack trace

[sleushunou]

dotnet/maui#28197

i found similar issue

[a1exv]

Happens for us in random places in the iOS in release mode. This is a blocker to go for net9

[afk013]

TLDR: Just to add a me too to this issue though our situation we can only repeat in a release mode and we only get InvalidCastException

This crash has only been recreated by us using a release-built iOS app with the default template AOT and trimming settings enabled. Attempting to create repro steps has been difficult as the crash is intermittent in that it seemingly can occur anywhere in the app however will occur multiple times within the span of a couple of hours for any given device (sometimes within 5 minutes of app start to around 1.5 hours of use).

It seems to happen during periods of heavy activity such as background syncing and the UI reacting to data changes or during page navigation.



Exception details:

*** Terminating app due to uncaught exception 'SIGABRT', reason: 'Arg_InvalidCastException'



Xamarin Exception Stack:

System.InvalidCastException: Arg_InvalidCastException

at System.Threading.Tasks.Task.RunContinuations(Object )

at System.Threading.Tasks.Task.FinishStageThree()

at System.Threading.Tasks.Task.FinishStageTwo()

at System.Threading.Tasks.Task.Finish(Boolean )

at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& , Thread )

at System.Threading.Tasks.Task.ExecuteEntryUnsafe(Thread )

at System.Threading.Tasks.Task.ExecuteFromThreadPool(Thread )

at System.Threading.ThreadPoolWorkQueue.DispatchItemWithAutoreleasePool(Object , Thread )

at System.Threading.ThreadPoolWorkQueue.Dispatch()

at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

This issue does look very similar to the issue raised here: #81211 however this was resolved in .Net MAUI 8 RC2 and we are using .Net MAUI 9.0.50 SR5.


We did have a theory that possibly the exception was being raised within an event handler that was using async void. To rule this out we have used the package: https://github.com/roubachof/Sharpnado.TaskMonitor to revert all event handlers back to returning void and if any tasks within these methods throw an exception this is now handled within a global error handler. Sadly, while this approach is definitely better moving forward it was not the cause of the unhandled exception we are experiencing on iOS.

[pme442]

Well, add me to this, too. Happening in release mode .Net MAUI 9.0.10. It's very random (could happen while refreshing a ListView, closing a modal page, opening a modal page, toggling a Switch control, displaying an activity indicator etc.).
Very, very similar to what @afk013 describes.

That being said, what is the game plan here?
Up until now, I've been able to support our users and provide emergency bug fixes via the Xamarin Forms app.
However, in 2 weeks, I will no longer be able to do this due to the April 2025 App Store Xcode requirement.
Since I've converted to Maui, performance has taken a hit. It runs poorly on any device with less than 3GB of RAM. I've done everything that the Maui documents encourage me to do to help performance (compiled bindings, simplified layouts etc.). Our app is complex with heavy processing due to business requirements that I can't change. Xamarin Forms handled it like a dream. So I was quite disappointed after all the work I've put into converting it to Maui.
Aside from that, I'm not at all comfortable releasing the Maui app since this issue, in particular, makes it unstable.

[steveisok]

That being said, what is the game plan here?

We're in the process of triaging to determine what the problem is. If we're able to pin it down, I'm hopeful we'll be able to suggest workarounds better than falling back to the interpreter.

If anyone can provide a simple repro, that would help speed everything up.