Bug 39346 - "Debug project code only" does not prevent the debugger from breaking on exception catchpoints in non-user code unless the exception is thrown and caught within a `Task.Delay ().ContinueWith ()`
Summary: "Debug project code only" does not prevent the debugger from breaking on exce...
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger (show other bugs)
Version: 6.0.0 (C7)
Hardware: PC Mac OS
: Normal normal
Target Milestone: master
Assignee: David Karlaš
Depends on: 39371
  Show dependency tree
Reported: 2016-03-04 03:07 UTC by Brendan Zagaeski (Xamarin Support)
Modified: 2017-01-17 23:49 UTC (History)
2 users (show)

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

Test case (235.37 KB, application/zip)
2016-03-04 03:07 UTC, Brendan Zagaeski (Xamarin Support)
Break on all exceptions, Xamarin Studio (75.95 KB, image/png)
2016-03-04 03:10 UTC, Brendan Zagaeski (Xamarin Support)
Debug project code only, Xamarin Studio (83.15 KB, image/png)
2016-03-04 03:10 UTC, Brendan Zagaeski (Xamarin Support)
Detailed version info (1.58 KB, text/plain)
2016-03-04 03:18 UTC, Brendan Zagaeski (Xamarin Support)

Description Brendan Zagaeski (Xamarin Support) 2016-03-04 03:07:01 UTC
Created attachment 15252 [details]
Test case

"Debug project code only" does not prevent the debugger from breaking on exception catchpoints in non-user code unless the exception is thrown and caught within a `Task.Delay ().ContinueWith ()`

The test case for this bug is identical to the test case for the XamarinVS Bug 39345. The problem in Xamarin Studio is almost identical to the problem in XamarinVS except for the improvement related to Bug 9615 as discussed below.

This also might be a tricky problem to solve if the soft debugger does not currently provide enough context about the exception to the IDEs to make this possible.

## Regression status: not a regression

### BAD: Cycle 7 Alpha 1 preview

Xamarin Studio 6.0 (build 4520) (a354b2c)
Mono 4.3.2 (ba2e5e4)
Xamarin.iOS (a8da28f)
Xamarin.Android (8f34ab4)

### BAD: Cycle 5 – Service Release 5

Xamarin Studio 5.9.8 (build 0) (cc5f6e5)
Mono 4.0.5 (1d8d582)
Xamarin.iOS (1f068b4)
Xamarin.Android (f7b9e87)

## How this bug relates to the fix for Bug 9615

The fix for Bug 9615 only helps in certain special cases (I think maybe when the exception never propagates to the main thread?). This is a nice enhancement, but it does not yet match the full functionality of Visual Studio's "Just My Code" feature for console C# apps.

You can see the effect of the fix for Bug 9615 if you modify the attached test case to wrap the try/catch block in `Class1.Foo()` within a `Task.Delay ().ContinueWith ()` [1]. If you make that change, then the "Debug project code only" setting has the _correct_ desired effect in Xamarin Studio 5.10.0 and higher.

[1] This modification makes the test case match the unit test that was written for Bug 9615:

## Setup steps for Xamarin Studio on Mac

1. Under "Run -> New Exception Catchpoint", select the "When an exception is thrown" option, and enter "System.Exception" in the corresponding text field, and ensure "Include subclasses" is enabled. (See the attached screenshot for "Break on all exceptions, Xamarin Studio".)

2. Enable the "Xamarin Studio -> Preferences -> Debugger [heading] -> Debug project code only; do not step into framework code." checkbox. (See the attached screenshot for "Debug project code only, Xamarin Studio".)

## Steps to test

1. Unzip the attached test case.

2. If you have cleaned or manually deleted the `bin\Release` folder for the "PortableClassLibrary1" PCL project, build the "PortableClassLibrary1" project in the Release configuration. (The other projects use a direct `.dll` reference to that library as an example of a "not my code" assembly. The Release configuration for the PortableClassLibrary1 project enables compiler optimizations and disables all debugging information [2].)

3. Debug the "NativePortable1.Droid" or "NativePortable1.iOS" project in the "Debug|AnyCPU" or "Debug|iPhoneSimulator" configuration, respectively.

[2] For additional information see "To distinguish user code from non-user code, Just My Code looks at open projects, symbol (.pdb) files, and program optimizations.", on:

## Expected result (as demonstrated by the console C# application when run in Visual Studio)

The debugger does not break on any exceptions.

(See Bug 39345 for additional details on how to run the console C# application in Visual Studio.)

## Actual result

The debugger breaks on the exception from `Class1.Foo()`.

BAD: XS 6.0 + NativePortable1.Droid
BAD: XS 6.0 + NativePortable1.iOS

(As I understand it, the behavior of the "NativePortable1.Console" application in Xamarin Studio is a separate consideration since it does not use the soft debugger, so that can be ignored for the purposes of this bug.)
Comment 1 Brendan Zagaeski (Xamarin Support) 2016-03-04 03:10:22 UTC
Created attachment 15257 [details]
Break on all exceptions, Xamarin Studio
Comment 2 Brendan Zagaeski (Xamarin Support) 2016-03-04 03:10:59 UTC
Created attachment 15258 [details]
Debug project code only, Xamarin Studio
Comment 3 Brendan Zagaeski (Xamarin Support) 2016-03-04 03:18:16 UTC
Created attachment 15259 [details]
Detailed version info
Comment 5 David Karlaš 2016-03-04 18:03:12 UTC
I fixed this on IDE side(https://github.com/mono/debugger-libs/commit/c93c555485e914f0d699019efb280d23eda58b53) but until Bug 39371 is fixed, this can't be merged(it would result into weird behaviour). Since this is not regression I'm moving this to C8.
Comment 6 David Karlaš 2016-08-18 10:46:55 UTC
Since this is depending on runtime bug, I'm setting target to master
Comment 7 Nate Cook 2017-01-17 23:49:31 UTC
Hey guys, I'm still interested in the ability to enable a breakpoint for System.Exception work only for user code. Recently I noticed XS C9 (currently in the beta channel) is breaking on handled ArgumentOutOfRange exceptions for Console.WriteLine which is making it almost impossible to keep the System.Exception breakpoint enabled. Are there any plans to address this?

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