Bug 11565 - SIGABRT when NSTimer action throws exception in certain circumstances
Summary: SIGABRT when NSTimer action throws exception in certain circumstances
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Library (Xamarin.Mac.dll) ()
Version: 1.2.x
Hardware: Macintosh Mac OS
: Low enhancement
Target Milestone: ---
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2013-04-03 18:36 UTC by steven.orth
Modified: 2016-07-20 18:41 UTC (History)
6 users (show)

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

Project containing code to produce the bug. See MainWindow.cs (19.25 KB, application/zip)
2013-04-03 18:36 UTC, steven.orth

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:

Description steven.orth 2013-04-03 18:36:06 UTC
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>

Native stacktrace:

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).
Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-05-21 17:22:51 UTC
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).
Comment 2 Rolf Bjarne Kvinge [MSFT] 2013-05-21 17:34:44 UTC
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.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2013-06-03 06:42:16 UTC
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.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2016-06-30 06:18:02 UTC
Exception marshaling has been implemented (but it's opt-in).
Comment 7 Chris Hamons 2016-07-20 18:41:55 UTC
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.