-
-
Notifications
You must be signed in to change notification settings - Fork 206
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
[iOS / Native AOT] Bad stack trace due to unsupported marshalling behavior #3280
Comments
Hm, I'm not sure I follow everything that's going on here but it seems like that assertion is also dependent on
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 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 |
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 sentry-dotnet/src/Sentry/Platforms/Cocoa/SentrySdk.cs Lines 14 to 17 in bea3fcf
|
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. |
@bitsandfoxes what do we want to do about this?
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. |
Would it not be possible to allow an optional/temporary way to disable the changing of marshalling bahavior, as I suggested above? |
I was able to run a Native AOT compiled app locally on a physical device using |
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. |
Package
Sentry
.NET Flavor
.NET
.NET Version
8.0.2
OS
iOS
SDK Version
4.2.1
Self-Hosted Sentry Version
No response
Steps to Reproduce
Crash in NativeAOT compiled iOS app (there might be more prerequisites, like the managed exception to be marshalled to native code and back to managed).
Expected Result
Crash with useful strack trace including managed C# function from where it originated
Actual Result
I believe this is caused because of this event handler that changes the default marshalling behavior of exceptions:
sentry-dotnet/src/Sentry/Platforms/Cocoa/SentrySdk.cs
Lines 14 to 17 in bea3fcf
The code was introduced after this discussion in the Xamarin repo: xamarin/xamarin-macios#15252
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:https://github.com/xamarin/xamarin-macios/blob/907081f787315704a01c940cf28b46b47db23df0/runtime/runtime.m#L2362-L2364
https://github.com/xamarin/xamarin-macios/blob/907081f787315704a01c940cf28b46b47db23df0/runtime/runtime.m#L2452-L2455
The text was updated successfully, but these errors were encountered: