Bug 3980 - MonoTouchException (wrapping ObjectiveC exceptions) crash on devices
Summary: MonoTouchException (wrapping ObjectiveC exceptions) crash on devices
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2012-03-19 16:33 UTC by Sebastien Pouliot
Modified: 2012-03-27 12:50 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Comment 1 Sebastien Pouliot 2012-03-19 17:28:41 UTC
Seems we're doing the conversion in the handler we provide to NSSetUncaughtExceptionHandler [1] which is supposed to end the application (on both iOS and OSX). Maybe it's the simulator that behaves badly... 

Not sure if we're really helping by allowing this to be catch, then resume execution on the simulator.

[1] https://developer.apple.com/library/ios/documentation/cocoa/reference/foundation/miscellaneous/foundation_functions/reference/reference.html#//apple_ref/c/func/NSSetUncaughtExceptionHandler
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-03-27 12:50:59 UTC
The crash is because the main thread has a objc try-catch handler at the top of the stack, which ends up messing badly with mono when the stack is unwound due to an objc exception.

If you run the code on a separate thread (threadpool for instance), the managed exception is thrown just like in the simulator.

This is quite a tricky problem to solve properly though, the real solution is to convert between NSException and managed exception on managed/native boundaries. Mono doesn't know how to handle native frames properly to not leak, etc, and objc doesn't know how to handle managed frames for the same reason (in fact objc exceptions are discouraged because they will cause leaks...).

But given that objc exceptions are even more exceptional than managed ones (they're recommended only for unrecoverable conditions, even though some API have abused a bit), I'm not sure it's worth it to fix this problem.

There are a few pain points though:
1) The only way to print better diagnostics is to actually add objc try-catch handlers in every managed->native transition. Right now we fail with a native stack trace that makes no sense (it's corrupted).
2) Some objc API are actually using exceptions for recoverable conditions (and right now we can recover from them, just not on the main thread), so just aborting sounds like a bad solution too.

For 1) I don't know what to do, since basic things such as pinvokes have to change. For now I don't think it's worth the effort (this doesn't seem to be an issue people run into often).

For 2) I suggest we modify our bindings whenever possible to detect the exceptional condition and throw a managed exception instead.