Bug 25356 - Debugger does not properly display exceptions thrown from async methods
Summary: Debugger does not properly display exceptions thrown from async methods
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger ()
Version: 4.20.0
Hardware: PC All
: High critical
Target Milestone: 6.0 (C6)
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2014-12-12 17:05 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-03-07 05:52 UTC (History)
11 users (show)

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


Attachments
Test case (21.00 KB, application/zip)
2014-12-12 17:05 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


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:
Status:
VERIFIED FIXED

Description Brendan Zagaeski (Xamarin Team, assistant) 2014-12-12 17:05:13 UTC
Created attachment 9062 [details]
Test case

Debugger does not properly display exceptions thrown from async methods.

The symptoms of this bug are similar to bug 24975, but this bug has existed for much longer.

The test case is just an Android template project with the button connected to an async method that throws an exception. A matching iOS project is included, and the debugger _does_ handle that case correctly. The iOS test case was recently broken and re-fixed in Visual Studio (bug 23076), but that is apparently unrelated.


Regression status: probably not a regression (see "Version Information").


## Partial workaround

Set the debugger to break on all exceptions. This allows the debugger to break on the exception when it is first thrown. The debugger then breaks on `throw new Exception("An Exception")`.

In the included properly working iOS test case, the debugger breaks on the outermost method of the call stack where the async method was invoked (`UIApplication.Main()`).


Note for any users attempting this workaround: this trick does work for me in Visual Studio, but not as well as in Xamarin Studio.

a. It doesn't work every time. Sometimes the app just hangs and Visual Studio never shows the exception.

b. Even when it does work, it often takes a _long_ time for the exception window to appear (about 60-70 seconds).


I tried it with the two most recent versions:

- Xamarin   3.8.150
- Xamarin   3.9.142.0



## Steps to reproduce

1. Debug the attached test case on device or emulator. (Tested in Visual Studio, Xamarin Studio for Windows, and Xamarin Studio for Mac.)

2. Tap the "Hello World, Click Me!" button.



## Results

### In Visual Studio: "Source Not Available" tab

Visual Studio pops up an "Unhandled Exception" dialog. After the user clicks "Break", Visual Studio open a new "Source Not Available" tab:

> Frame not in module
>
> The current stack frame was not found in a loaded module. Source cannot be
> shown for this location.
>
> You can view disassembly in the Disassembly window. To always view
> disassembly for missing source files, change the setting in the Options
> dialog.


### Call stack when the debugger first breaks (same in VS and XS)
> System.Diagnostics.Debugger.Mono_UnhandledException_internal ()
> System.Diagnostics.Debugger.Mono_UnhandledException (ex=)
> object.648e36c1-f4bf-4b44-a8f7-bdff2ae2c820 (Parameters=)
> System.Runtime.CompilerServices.AsyncVoidMethodBuilder.AnonymousMethod__0 (Parameters=)
> Android.App.SyncContext.Post.AnonymousMethod__0 (Parameters=)
> Java.Lang.Thread.RunnableImplementor.Run (Parameters=)
> Java.Lang.IRunnableInvoker.n_Run (Parameters=)
> object.648e36c1-f4bf-4b44-a8f7-bdff2ae2c820 (Parameters=)

At this point the "Locals" pad is empty.


### Call stack after executing "Run -> Continue Debugging" once (same in VS and XS)
> object.648e36c1-f4bf-4b44-a8f7-bdff2ae2c820 (Parameters=)


Now the "Locals" pad contains a `$exception` local variable:

> System.Exception: An Exception
>   at AndroidApp1.MainActivity+<Method1>c__async1.MoveNext () [0x00093] in /Volumes/ramdisk/JRowse/AsyncException/AndroidApp1/MainActivity.cs:37 
> --- End of stack trace from previous location where exception was thrown ---
>   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in <filename unknown>:0 
>   at System.Runtime.CompilerServices.TaskAwaiter`1[System.Int32].GetResult () [0x00000] in <filename unknown>:0 
>   at AndroidApp1.MainActivity+<button_Click>c__async0.MoveNext () [0x00022] in /Volumes/ramdisk/JRowse/AsyncException/AndroidApp1/MainActivity.cs:31 


### The "Application Output" contains the correct exception message

> [MonoDroid] UNHANDLED EXCEPTION:
> [MonoDroid] System.Exception: An Exception
> [MonoDroid]   at AndroidApp1.MainActivity+<Method1>c__async1.MoveNext () [0x00093] in /Volumes/ramdisk/JRowse/AsyncException/AndroidApp1/MainActivity.cs:37 
> [MonoDroid] --- End of stack trace from previous location where exception was thrown ---
> [MonoDroid]   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in <filename unknown>:0 
> [MonoDroid]   at System.Runtime.CompilerServices.TaskAwaiter`1[System.Int32].GetResult () [0x00000] in <filename unknown>:0 
> [MonoDroid]   at AndroidApp1.MainActivity+<button_Click>c__async0.MoveNext () [0x00022] in /Volumes/ramdisk/JRowse/AsyncException/AndroidApp1/MainActivity.cs:31 


### Version information

Microsoft Visual Studio Professional 2013
Version 12.0.30723.00 Update 3
Microsoft .NET Framework
Version 4.5.51641

### Bad Windows
Xamarin   3.3.47.0 (0b2a123923812a88ed3091909478dbe9e0111f00)

### Bad Windows
Xamarin   3.7.248.0 (8ca7d11db8a6f874c6cd2de6d9ca0f511867ce91)
Xamarin.Android   4.18.1.3 (5474129af31e9d3a86cb7482c7c5c7a30ad315f1)
Xamarin.iOS   8.4.0.0 (209abebbd8f1a292d042420edb45fa5fbd3f017b)

### Bad Windows
Xamarin   3.9.142.0 (e7bacad)
Xamarin.Android   4.20.0.34 (49a04b966feb40dfdba49d57ba16249b66d606a6)
Xamarin.iOS   8.6.0.0 (22574c9788a6d607f8d119e4d645f5ce5a346553)


### Bad Mac

Mac OS X 10.9.5

=== Xamarin Studio ===

Version 5.7 (build 646)
Installation UUID: 2c0ea975-8f73-4920-8414-3e9ae359fbf4
Runtime:
	Mono 3.12.0 ((detached/dc0ce1d)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000066

=== Xamarin.Android ===

Xamarin.Android 4.20.0.28 (Business Edition)
Android SDK: /Users/macuser/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		4.0    (API level 14)
		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: /Users/macuser
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Build Information ===

Release ID: 507000646
Git revision: 4574f534cc8c822ac1a4b2f31450250afb6511d3
Build date: 2014-12-09 16:28:52-05
Xamarin addins: c3c87b666323c163f0ad02618d1753533cf0a4f9
Comment 3 Parmendra Kumar 2014-12-18 08:53:17 UTC
I have checked this issue and I am also getting same behavior described in the bug description. To reproduce this issue I have followed the attached sample project in bug description.

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

ApplicationOutput: https://gist.github.com/Parmendrak/49337fc1b56ab817f0fc
IDE Log: https://gist.github.com/Parmendrak/c3c90551e290f7135cb9
BuildOutput: https://gist.github.com/Parmendrak/c216e79890a520575114

Environment info: https://gist.github.com/Parmendrak/43830473e9457072f21d
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-20 19:39:22 UTC
I'm hiding comment 4 and comment 5 to prevent confusion (in the end, those comments were about a separate problem). I am also accordingly resetting the status back to CONFIRMED from comment 3.

To publicly preserve one bit of information from comment 4 that might be helpful, I will paraphrase it here:

One (admittedly somewhat "self-defeating") way to avoid the problem would be to wrap all code that runs in async contexts in try/catch blocks, and then only break on specific _handled_ exceptions in the debugger. But of course from the IDE debugging standpoint, that's essentially the same as the "partial workaround" from comment 0.

As a refinement on the "partial workaround" in comment 0, it is indeed sufficient to break only on the _particular_ thrown exception of interest. So for example, for the original test case in comment 0, it is sufficient to set the debugger to break specifically when the `System.Exception` type is thrown. Minimizing the list of "break if thrown" exceptions seems to improve the debugger start-up performance.

As one more small piece of follow-up, some quick informal tests suggest that using the "minimal list of break if thrown exceptions" workaround in combination with the latest versions of XamarinVS works fairly well. The exception window now seems to pop-up every time after only a short delay.
Comment 7 Jonathan Pryor 2015-08-03 15:47:24 UTC
This should be "fixed" in monodroid/5cef6a7b, which enables the Xamarin.Android 4.x-style exception filters when the debugger is attached, as opposed to the current 5.x-style "catch all exceptions and propagate through Java" approach.
Comment 8 kpickard@flightdocs.com 2015-08-17 22:59:40 UTC
What version is monodroid/5cef6a7b?
Comment 9 Jonathan Pryor 2015-08-18 21:42:56 UTC
@kpickard: That will correspond to "Cycle 6".
Comment 10 Parmendra Kumar 2015-10-05 06:37:06 UTC
I have checked this issue with C6 build and now its working fine.

Hence closing this issue.

Environment info:

=== Xamarin Studio ===

Version 5.10 (build 811)
Installation UUID: 1a096c6f-0678-402e-89b2-a2c10f7e80e4
Runtime:
	Mono 4.2.1 (explicit/cc1cf60)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402010062

=== Xamarin.Profiler ===

Version: 0.22.156.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.0 (8227)
Build 7A220

=== Xamarin.Mac ===

Version: 2.4.0.79 (Enterprise Edition)

=== Xamarin.Android ===

Version: 6.0.0.8 (Enterprise Edition)
Android SDK: /Users/360_macmini/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)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 24.3.4
SDK Platform Tools Version: 23.0.1
SDK Build Tools Version: 23.0.1

Java SDK: /usr
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

=== Xamarin Android Player ===

Version: 0.4.4
Location: /Applications/Xamarin Android Player.app

=== Xamarin.iOS ===

Version: 9.2.0.84 (Enterprise Edition)
Hash: b5396c2
Branch: master
Build date: 2015-09-30 15:22:15-0400

=== Build Information ===

Release ID: 510000811
Git revision: 34cd31ea72536afab530c14d9220b286075e83cd
Build date: 2015-09-30 10:40:37-04
Xamarin addins: 8e6fccfc0c19a7e0b7b11be925f09751d827eb5c
Build lane: monodevelop-lion-cycle6

=== Operating System ===

Mac OS X 10.10.5
Darwin ShrutiMac.local 14.5.0 Darwin Kernel Version 14.5.0
    Wed Jul 29 02:26:53 PDT 2015
    root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
Comment 11 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-03 19:43:34 UTC
## Clarification on Comment 7 and the status of this bug

The change mentioned in Comment 7 restores this bug to its original reported behavior as described in Comment 0.

Comment 7 is in fact addressing the other bug I mentioned in Comment 0: non-public Bug 24975.

Comment 0 is about the behavior in XA 4.x (and earlier) and XA 6.x (and later), and _only_ affects exceptions from `async` methods, while Bug 24975 is about the behavior in XA 5.x and affects _all_ exceptions.




## Behavior of Xamarin.Android 6.0 ("Cycle 6") for this bug

Xamarin.Android 6.0 behaves approximately identically to Xamarin.Android 4.x when debugging the attached test case.

In retrospect, I think my original report in Comment 0 included too much information, making it difficult to see what the core request was for this bug report. I will now focus on just the behavior in Visual Studio because I think that will make it easier to describe.


### Actual behavior

On Android, after you click the "Break" button in the exception pop-up window:

- Visual Studio shows a "Source Not Available" tab. 
- The "Locals" windows is _empty_.


### Expected behavior

On iOS, after you click the "Break" button in the exception pop-up window:

- Visual Studio does _not_ show a "Source Not Available" tab.
- The "Locals" window is _not_ empty.




## Next steps

Both because the symptoms of this bug look deceptively similar to Bug 24975, and because this bug is in part about achieving consistent behavior across iOS and Android apps, it will perhaps be helpful if I create an internal document to describe the desired behavior for this bug. I will submit that document to the product management and engineering teams.

For now I will leave the bug status unchanged while awaiting feedback on that document.



## Version info

XamarinVS 4.0.0.1649 (90e1af2) ("Cycle 6 RC 1")