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.
Created attachment 3746 [details]
Project containing code to produce the bug. See MainWindow.cs
If you use a try / catch block around code that uses an NSTimer, and the timer's action throws an exception, an error similar to the following occurs:
2013-04-03 17:33:52.987 NSTimerTest[47564:1e07] *** Exception handlers were not properly removed. Some code has jumped or returned out of an NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or NS_VALUERETURN macros.
NSTimerTest(47564,0xac9172c0) malloc: *** error for object 0x1: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
at (wrapper managed-to-native) MonoMac.AppKit.NSApplication.NSApplicationMain (int,string) <IL 0x0009d, 0xffffffff>
at MonoMac.AppKit.NSApplication.Main (string) [0x0003c] in /Users/builder/data/lanes/xamcore-lion-bs1/0c83ca0e/source/xamcore/monomac/src/AppKit/NSApplication.cs:98
at NSTimerTest.MainClass.Main (string) [0x00005] in /Users/steveno/projects/NSTimerTest/NSTimerTest/Main.cs:14
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>
As a workaround, do not let the exception escape the proc, and deal with it in some other way.
See attached project to reproduce (MainWindow.cs).
Fixing this would require us to convert managed exceptions into ObjC exceptions on every native-to-managed transition, and ObjC exceptions to managed exceptions on every managed-to-native transition.
This is not a trivial change, and it will take time to implement properly (if in fact we decide to do it. There are a few drawbacks, such as slowing down every native-managed transition).
Another issue is that Objective-C exceptions are not supposed to be thrown lightly, they're only supposed to be used when something went really, really wrong.
"Furthermore, most of the Cocoa frameworks are not exception safe. Thus, throwing an exception through Cocoa framework code is dangerous and will likely cause odd, difficult to diagnose, and catastrophic (think possible data loss) bugs in your app." - from http://stackoverflow.com/a/3679313/183422
This affects the native-to-managed transition, when we'd convert managed exceptions to Objective-C exceptions - we might very well end up with all kinds of problems if we for instance try to convert a trivial FormatException into an Objective-C exception.
One thing we could do fairly easily is to wrap NSTimer ticks in try/catch handlers which could raise the AppDomain.UnhandledException event if an exception is caught. You'd still have to listen for that event and cope with it appropriately though.
Exception marshaling has been implemented (but it's opt-in).
QA - You will need to add this to your mmp additional arguments to verify this issue:
This feature is opt-in for now, since it is not backwards compatible.