Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Seems we're doing the conversion in the handler we provide to NSSetUncaughtExceptionHandler  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.
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.