Issues with unhandled exceptions #15252
Comments
|
A potential workaround would be to add event handlers to the Ref: https://docs.microsoft.com/en-us/xamarin/ios/platform/exception-marshaling#events |
rolfbjarne
added
bug
|
Thanks. After testing with those, I find that by default the same thing happens there as well. However, if I set the AppDomain.CurrentDomain.UnhandledException += (sender, args) =>
{
Console.WriteLine("In UnhandledException Handler");
};
AppDomain.CurrentDomain.FirstChanceException += (sender, args) =>
{
Console.WriteLine("In FirstChanceException Handler");
};
ObjCRuntime.Runtime.MarshalManagedException += (sender, args) =>
{
Console.WriteLine("In MarshalManagedException Handler");
args.ExceptionMode = ObjCRuntime.MarshalManagedExceptionMode.UnwindNativeCode;
};
ObjCRuntime.Runtime.MarshalObjectiveCException += (sender, args) =>
{
Console.WriteLine("In MarshalObjectiveCException Handler");
};
throw new Exception("Test Exception");My debug output now includes the following: So it seems I can workaround the issue for now by using I am a bit confused why this works though. The doc you pointed at says:
So, why does setting |
We changed the default in .NET, and that page hasn't been updated yet: |
Yes, I think that should work fine. |
|
Thanks! |
|
Confirming that the same problem exists for macOS applications, and that setting the exception mode to Unwind doesn't seem to make |
|
I think the comments in this file also have to be updated to reflect what is now the default: https://github.com/xamarin/xamarin-macios/blob/main/src/ObjCRuntime/ExceptionMode.cs |
@rolfbjarne Does this workaround apply to Xamarin.iOS as well? It seems that Runtime.MarshalManagedException, Runtime.MarshalObjectiveCException and AppDomain.CurrentDomain.UnhandledException don't trigger at all in Release mode in Xamarin.iOS unless --interpreter=all is set. Unfortunately, enabling the interpreter in Xamarin.iOS for us is a huge performance hit. |
Yes, but you must explicitly enable exception marshalling (we turned it on by default in .NET). You can do that by adding this to the additional mtouch arguments in the project's iOS Build options (this is the MtouchExtraArgs property in the csproj). |
|
Has this issue been resolved in .NET 7?
For a .NET 7 macOS application, it looks like the AppDomain.UnhandledException is not triggered at all. I tested it by throwing a managed exception on the main thread. I can see that the Runtime.MarshalManagedException is fired, but then setting the ExceptionMode to UnwindNativeCode doesn't fire the UnhandledException either, it just crashes the app. |
No, it's not been fixed yet. |
|
A few updates:
This has been fixed (9b8869b). In my test case,
We can probably fix the fourth, but we likely won't be able to fix the second and third.
This is not fixed. In fact there doesn't seem to be a way for us to call this handler, the managed runtime does it automatically during exception handler. Unfortunately we're somewhat exceptional, so the existing logic in the managed runtime doesn't work for us. |
|
I've filed dotnet/runtime#102730 to see if we can find a way to raise the UnhandledException event. |
rolfbjarne
added
the
dotnet-external-dependency
…xception. (#20656) Call mono_unhandled_exception to raise AppDomain.UnhandledException when managed exceptions are unhandled. Partial fix for #15252 (for MonoVM, still pending for CoreCLR, which needs dotnet/runtime#102730 fixed first).
|
The problem with the |
Steps to Reproduce
On a Mac, after installing the latest 6.0.300 SDK and the
iosworkload:dotnet new iosAppDelegate.cs. At the end ofFinishedLaunching, beforereturn true;insert the following code:dotnet runExpected Behavior
The output should indicate that the
FirstChanceExceptionhandler fires once, and then theUnhandledExceptionhandler should fire once. Then I should get a crash report window from macOS (if applicable).Actual Behavior
The log shows that the
FirstChanceExceptionhandler fires over 1000 times (the exact number seems to vary). TheUnhandledExceptionhandler never fires. I do get the crash report window from macOS.Environment
Version information
Crash Report
I think this is similar to the issues reported in #12040 and #14796, but I'm not certain. Is there any workaround? If not, I don't think should wait for .NET 7.
The text was updated successfully, but these errors were encountered: