Bug 32383 - [Linker] Enabling the Android linker causes breakpoints set on newly added lines of code in PCLs to be ignored by Xamarin Studio until they are re-set
Summary: [Linker] Enabling the Android linker causes breakpoints set on newly added li...
Alias: None
Product: Android
Classification: Xamarin
Component: Tools and Addins ()
Version: 5.1
Hardware: PC Mac OS
: Normal normal
Target Milestone: 6.0 (C6)
Assignee: Radek Doulik
Depends on:
Reported: 2015-07-23 22:54 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-09-14 09:53 UTC (History)
6 users (show)

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

Test case (267.22 KB, application/zip)
2015-07-23 22:54 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Logs and version information (96.64 KB, application/zip)
2015-07-23 22:55 UTC, Brendan Zagaeski (Xamarin Team, assistant)

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 Brendan Zagaeski (Xamarin Team, assistant) 2015-07-23 22:54:57 UTC
Created attachment 12201 [details]
Test case

Enabling the Android linker causes breakpoints set on newly added lines of code in PCLs to be ignored by Xamarin Studio until they are re-set

## Regression status: not yet determined

## Steps followed to reproduce

1. Open the attached test case in Xamarin Studio on Mac.

2. Add a line similar to `var w = 5;` before `var x = 10;` in `FormsApp1/App.cs`.

3. Set a breakpoint on the new line from step 2.

4. Start debugging the app in the "Debug" configuration.

5. Tap the "Click this button" button.

## Results

The IDE does not break on the breakpoint from step 3.

## Ways to alter the outcome (so the breakpoint _is_ hit)

- Change the "Project Options -> Android Build -> Link [tab] -> Linker behavior" to "Don't link".


- a. After step 5, restart Xamarin Studio.
  b. Then unset and re-set the breakpoint from step 3.
  c. Then repeat steps 4 & 5.

In my tests it seemed to take a few repetitions of steps (b) and (c) to get the breakpoint to work (?). Maybe the IDE is caching some information about the breakpoints?

## Results in Visual Studio and Xamarin Studio on Windows

The breakpoint is hit on the first attempt.

## Additional version info (brief)

### Devices

Xamarin Android Player 0.3.7 (1), Nexus 4 (KitKat)

### OS X 10.10.4

(Also tested with the same results in an OS X 10.10.0 VM image.)
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-07-23 22:55:39 UTC
Created attachment 12202 [details]
Logs and version information
Comment 2 David Karlaš 2015-07-24 00:41:51 UTC
This is fixed in Xamarin.Android master and will be part of Cycle 6

*** This bug has been marked as a duplicate of bug 18824 ***
Comment 4 Brendan Zagaeski (Xamarin Team, assistant) 2015-07-24 01:05:40 UTC
Unfortunately, I'm pretty sure it's something different from Bug 18824
specifically. The test case from Bug 18824 no longer reproduces on the current
Alpha versions of Cycle 5 SR 3, whereas I just found this behavior (Bug 32383)
today on the current Alpha versions.

- This bug is specific to Xamarin Studio, while Bug 18824 was not.

- The behavior of this bug is a bit more "peculiar" than Bug 18824. The
breakpoint does _eventually_ work even with linking _enabled_. On Bug 18824,
the call stack for the exception _never_ had the correct line numbers with
linking enabled.

All that said, it is still fully possible that the changes in Cycle 6 do fix
this bug.

I'm happy to test with master builds, or QA can try. For now, I'll set the
status as RESOLVED FIXED to prompt QA to try verifying this specific bug on the
Cycle 6 builds, in case they get a chance before I do.
Comment 6 David Karlaš 2015-07-24 03:29:29 UTC
I'm able to reproduce this, hence setting status to REOPENED
Comment 7 David Karlaš 2015-07-27 10:56:09 UTC
Problem is caused by Linker changing column lines in .mdb to 0(zero). Which causes XS think there is some other method(anonymous) inside method and doesn't place breakpoint...
Comment 8 Jonathan Pryor 2015-08-03 10:24:09 UTC
@David: Would it be possible to "improve" Xamarin Studio so that it doesn't assume that a column value of 0 is only for anonymous methods?

The column value of 0 is a Cecil bug, and (1) we don't know if we can fix it in the current Cecil branch, and (2) while we want to bump to a more recent Cecil branch, that's a Cycle 7 project.
Comment 9 Jonathan Pryor 2015-08-06 17:20:45 UTC
David notes that code such as this:

    for(int i=0;**i<10**;i++){ /* all on one line */ }

won't work when column values are always 0, because there's no way to know where one statement ends and the other begins.

This is true, but is hopefully a minority enough of code that it won't be a huge problem.
Comment 10 David Karlaš 2015-08-17 09:50:58 UTC
I made workaround in Xamarin Studio to place breakpoint if column is 0 in this commit: https://github.com/mono/debugger-libs/commit/ea475a9935c1d10bdbdd0c0d21aeb86a2f45e624

But please, make sure to fix this properly in Cycle 7, since there are still bugs caused by this like placing breakpoints on instructions where multiple instructions are in same line...
Comment 11 Radek Doulik 2015-09-04 08:14:11 UTC
This is fixed in master by https://github.com/mono/cecil/commit/13b9d56aa0d426670348b204c7f49ace2386080b
Comment 12 Radek Doulik 2015-09-09 07:40:20 UTC
It is now fixed in cycle6 branch as well.