Bug 26786 - App crashes silently when an exception is raised by a destructor
Summary: App crashes silently when an exception is raised by a destructor
Status: CONFIRMED
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger (show other bugs)
Version: unspecified
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Zoltan Varga
URL:
: 27343 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-05 16:07 UTC by Adam Kapos
Modified: 2016-01-04 20:30 UTC (History)
9 users (show)

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


Attachments
Sample created. (11.84 KB, application/x-zip-compressed)
2015-07-06 11:29 UTC, Abhishek
Details

Description Adam Kapos 2015-02-05 16:07:09 UTC
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:

<Warning>: 
	Unhandled Exception:
	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.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2015-02-06 11:09:26 UTC
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." [1]

So the problem is how the exception is handled when debugging, and not that the app terminates.

[1] https://msdn.microsoft.com/en-us/library/system.object.finalize(v=vs.110).aspx
Comment 2 Adam Kapos 2015-02-06 11:19:08 UTC
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.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2015-02-24 06:09:41 UTC
*** Bug 27343 has been marked as a duplicate of this bug. ***
Comment 4 Jeffrey Stedfast 2015-02-24 11:10:44 UTC
There's no way for Xamarin Studio to prevent the app from crashing, so not sure why this got reassigned to me?
Comment 5 Rolf Bjarne Kvinge [MSFT] 2015-02-24 11:12:54 UTC
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.
Comment 6 Adam Kapos 2015-02-24 11:15:06 UTC
Or at least print something meaningful to the application output :)
Comment 7 Abhishek 2015-07-06 11:29:22 UTC
Created attachment 11884 [details]
Sample created.

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.

Screencast: http://www.screencast.com/t/oMoy59Nw

Build output: https://gist.github.com/Rajneesh360Logica/035cacc9a1f1cbb875ee
Device logs: https://gist.github.com/Rajneesh360Logica/bb9f59822ff1a1fbdc0a
Ide Logs: https://gist.github.com/Rajneesh360Logica/15db2c244851a7c37f8b

Environment Info:

=== Xamarin Studio ===

Version 5.9.4 (build 5)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Runtime:
	Mono 4.0.2 ((detached/c99aa0c)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400020005

=== Xamarin.Android ===

Version: 5.1.4.16 (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)
Build 6C131e

=== Xamarin.iOS ===

Version: 8.10.2.43 (Business Edition)
Hash: 428e4d4
Branch: master
Build date: 2015-07-03 10:41:01-0400

=== Xamarin.Mac ===

Version: 2.0.2.43 (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
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
Comment 8 Lluis Sanchez 2015-07-06 13:30:26 UTC
If the debugger doesn't stop in the exception, that's a problem in the debugger.
Comment 9 Zoltan Varga 2015-07-07 17:14:15 UTC
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.
Comment 10 David Karlaš 2016-01-04 20:30:00 UTC
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...

Note You need to log in before you can comment on or make changes to this bug.