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 for Bug 26786 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
When an exception is raised by a destructor the app crashes silently. There is no way to catch it or break the debugger when it happens. No error is displayed in Xamarin Studio's application output pad.
However, this shows up on the device console:
0 SomeiOSApp 0x0346f9c9 mono_handle_exception_internal + 2532
1 SomeiOSApp 0x0346efdf mono_handle_exception + 10
2 SomeiOSApp 0x03468c6b mono_arm_throw_exception + 110
3 SomeiOSApp 0x00b03738 throw_exception + 64
at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0x00070>
5 SomeiOSApp 0x0349e09d mono_gc_run_finalize + 344
6 SomeiOSApp 0x034debb9 mono_gc_invoke_finalizers + 248
7 SomeiOSApp 0x0349ed0b finalizer_thread + 342
8 SomeiOSApp 0x03500eb7 start_wrapper + 310
9 SomeiOSApp 0x0351a72f inner_start_thread + 158
10 libsystem_pthread.dylib 0x35a61e67 <redacted> + 138
11 libsystem_pthread.dylib 0x35a61ddb _pthread_start + 118
12 libsystem_pthread.dylib 0x35a5fb84 thread_start + 8
To make things really confusing, it is sometimes followed with a stack trace, which does show up in the application output.
It does not produce any crash report in the device logs.
The expected behavior is that the process terminates:
(from MSDN): "If Finalize or an override of Finalize throws an exception, [...], the runtime terminates the process and no active try/finally blocks or finalizers are executed." 
So the problem is how the exception is handled when debugging, and not that the app terminates.
Yes. While the practice itself is really really bad, the debugger should still break, especially when a breakpoint is set to break on all exceptions.
*** Bug 27343 has been marked as a duplicate of this bug. ***
There's no way for Xamarin Studio to prevent the app from crashing, so not sure why this got reassigned to me?
Jeff, as explained in comment 1 the problem isn't that the app is crashing, but that the debugger doesn't break when configured to break on exceptions.
Or at least print something meaningful to the application output :)
Created attachment 11884 [details]
I have checked this issue and I am also able to reproduce the reported behaviour. To reproduce this issue I have created a sample with the help of instruction provided in bug description.
Steps to reproduce:
1. Open attached test sample in XS.
2. Build and run the application.
3. Click on the button.
4. Observed that application will crash silently.
Build output: https://gist.github.com/Rajneesh360Logica/035cacc9a1f1cbb875ee
Device logs: https://gist.github.com/Rajneesh360Logica/bb9f59822ff1a1fbdc0a
Ide Logs: https://gist.github.com/Rajneesh360Logica/15db2c244851a7c37f8b
=== Xamarin Studio ===
Version 5.9.4 (build 5)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Mono 4.0.2 ((detached/c99aa0c)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400020005
=== Xamarin.Android ===
Version: 184.108.40.206 (Business Edition)
Android SDK: /Users/MM/Desktop/android-sdk-macosx
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
=== Xamarin Android Player ===
Version: Unknown version
Location: /Applications/Xamarin Android Player.app
=== Apple Developer Tools ===
Xcode 6.2 (6776)
=== Xamarin.iOS ===
Version: 220.127.116.11 (Business Edition)
Build date: 2015-07-03 10:41:01-0400
=== Xamarin.Mac ===
Version: 18.104.22.168 (Business Edition)
=== Build Information ===
Release ID: 509040005
Git revision: 8010a90f6e246b32364e3fb46ef2c9d1be9c9a2b
Build date: 2015-06-08 16:52:06-04
Xamarin addins: 7e93e9c3503f28770f23ce1b7eafd829919f18e8
=== Operating System ===
Mac OS X 10.9.5
Darwin MacMini.local 13.4.0 Darwin Kernel Version 13.4.0
Sun Aug 17 19:50:11 PDT 2014
If the debugger doesn't stop in the exception, that's a problem in the debugger.
I can't reproduce this. If I set an exception catchpoint, the debugger pauses when the exception is thrown. Without the catchpoint, it doesn't pause, but I think thats the expected behavior.
It's true, if you explicitly create catchpoint it get caught, problem is that XS always has enabled UnhandledExceptionsCatchpoint... which is not called when exception is throw in destructor... hence bug...