According to @rolfbjarne from the .NET iOS/macOS team, CoreCLR (which is what is used on iOS when using Native AOT as well as on macOS) doesn't support MarshalManagedExceptionMode.UnwindNativeCode and therefore, this assertion is crashing the process:

Hm, I'm not sure I follow everything that's going on here but it seems like that assertion is also dependent on xamarin_is_gc_coop, which is only true when TARGET_OS_WATCH:

#if TARGET_OS_WATCH
bool xamarin_is_gc_coop = true;
#else
bool xamarin_is_gc_coop = false;
#endif

I can't see anything from Sentry in that stack trace though. Do you know what kind of exception was originally thrown (that resulted in this stack trace)?

I don' think it is dependent on xamarin_is_gc_coop. I might have posted links from the wrong commit, this one shows how the xamarin_assertion_message method is called in line 2441, like in the stack trace:
https://github.com/xamarin/xamarin-macios/blob/ed26faa94fe2734d9c1014d2e6ef7173d4d77690/runtime/runtime.m#L2441
and then abort() in line 1461:
https://github.com/xamarin/xamarin-macios/blob/ed26faa94fe2734d9c1014d2e6ef7173d4d77690/runtime/runtime.m#L1461

I don't know what exception was originally thrown (that's what I'm trying to find out), @rolfbjarne recommended that I should also subscribe to the ObjCRuntime.Runtime.MarshalManagedException event and then log the exception manually (more on that is documented here. UnwindNativeCode is documented as This isn't available when [...] when using CoreCLR).

OK thanks, that makes more sense. If we can find a way to throw an exception that reproduces this behaviour then we should be able to work out a solution 👍🏻

@jamescrosswell you can reproduce this behavior / stack trace by simply throwing an exception in the AppDelegate.FinishedLaunching method in an NativeAot-compiled app. You might have to upload a build to TestFlight as (to my knowledge) it is not possible to run NativeAOT compiled iOS apps locally.
Since there will be more adoption of NativeAOT in the future (e.g. with the launch of .NET 9), would it be possible to optionally disable this part of the Sentry initialization, so that the unsupported marshalling behavior isn't used?

would it be possible to optionally disable this part of the Sentry initialization

We could definitely put these on the Cocoa specific native options - like we do with the LogCat options for Android.

Upping the priority on this as it crashes the process.

Upping the priority on this as it crashes the process.

@bitsandfoxes what do we want to do about this?

you might have to upload a build to TestFlight as (to my knowledge) it is not possible to run NativeAOT compiled iOS apps locally.

Realistically, we can't test for things like this until/unless we create a developer profile and an app in the Apple store that we start down the QA route. Having done that once personally for a Flutter app, I suspect it's going to take about 3-5 days to get this all setup via CI so that we can easily deploy new versions of our app (e.g. Sentry.Samples.MAUI) to the iOS store... there are various encryption/deployment keys to manage that we'll need to sync between CI and our local machines etc.

I don't think we've got the bandwidth to do this right now. Perhaps once we've sorted out what we're going to do about net9.0 (and the device tests) we could circle back to this.

@bitsandfoxes what do we want to do about this?

Would it not be possible to allow an optional/temporary way to disable the changing of marshalling bahavior, as I suggested above?
I don't know if it would really work, but at the moment, the stack traces are just barely understandable...

I was able to run a Native AOT compiled app locally on a physical device using dotnet publish /t:Run /p:_DeviceName=DEVICEID where DEVICEID can be queried using xcrun xctrace list devices

I was able to run a Native AOT compiled app locally on a physical device using dotnet publish /t:Run /p:_DeviceName=DEVICEID where DEVICEID can be queried using xcrun xctrace list devices

That helps... it means we don't have to push it all the way through to test flight. Just a bit of fluffing around setting up encryption keys, developer profiles and configuring an app in the apple dev portal.

So it sounds a little less painful, when we do have the bandwidth to look into this.

@tipa I'm just looking at this issue and, embarrassingly, you opened it in April last year!

In any event, I'm a bit stuck. Bryce created a PR attempting to fix this but when I tested it out, I didn't see any noticeable difference in the stack traces with MarshalManagedExceptionMode.UnwindNativeCode and MarshalManagedExceptionMode.Disabled... So it doesn't look like that code is causing the problem.

Ultimately, the problem is that you're not getting very useful stack traces for exceptions in AOT Compiled applications though right?

Yes I didn't receive useful stack traces, because the app process crashed here when going through the native & managed layers: https://github.com/xamarin/xamarin-macios/blob/907081f787315704a01c940cf28b46b47db23df0/runtime/runtime.m#L2362-L2364 - at least this is the explanation I got from @rolfbjarne.

I am currently not using Sentry because I had to remove it after this problem while migrating to .NET9. At the moment I am just registering to the Runtime.MarshalManagedException event and logging exceptions to my backend, without altering the MarshalManagedExceptionMode. The stack traces look good.

I don't know why you don't see any difference in your tests. But from what I can tell based on your screenshot (#3729 (comment)), the stack trace looks pretty similar to the one I posted and also contains this part that indicates the app being aborted due to unsupported marshaling behavior:

Thanks again for all the info @tipa, as always.

I am currently not using Sentry because I had to remove it after #3620 while migrating to .NET9.

That's a shame. That was due to an issue in the Apple tooling, which was resolved in the XCode 16.2 release.

At the moment I am just registering to the Runtime.MarshalManagedException event and logging exceptions to my backend, without altering the MarshalManagedExceptionMode. The stack traces look good.

Arggh. Frustrating. I'll give it another go - although it feels a bit like Einstein's definition of insanity at this point!

When I create a blank iOS app (dotnet new ios) and throw an exception in FinishedLaunching while running with NativeAot, I do not get this part in the native stack trace (gathered by NSThread.NativeCallStack), which would indicate the process crashing here.

Thread 0 Crashed:
0   libsystem_kernel.dylib          0x39fe95fbc         __pthread_kill
1   libsystem_pthread.dylib         0x3e519567c         pthread_kill
2   libsystem_c.dylib               0x3210abb8c         abort
3   MyXYTestApp                     0x20499ce8c         xamarin_assertion_message (runtime.m:1461)

In your screenshot, these lines still seem to be present:

I also cannot reproduce the stack trace at the moment when using my own logging, the top of the stack trace always looks like the one below, even when setting the ExceptionMode to UnwindNativeCode - maybe it's because I have a different setup (e.g. no native library catching and sending out the crash report):

0   test                                0x00000001050f9ef0 xamarin_log + 6740
1   test                                0x00000001049ca660 test + 206432
2   test                                0x0000000104e28d80 test + 4787584
3   test                                0x0000000104e10b00 test + 4688640
4   test                                0x00000001050f0f94 xamarin_get_block_descriptor + 8052

Wish I could provide more help, but I'm also no expert in the matter, unfortunately.