Bug 3544 - Regression: Cannot set a breakpoint inside anonymous method
Summary: Regression: Cannot set a breakpoint inside anonymous method
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: Trunk
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2012-02-20 05:28 UTC by Marek Safar
Modified: 2012-04-18 17:43 UTC (History)
5 users (show)

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

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 Marek Safar 2012-02-20 05:28:30 UTC
using System;

class MainClass
	public static void Main (string[] args)
		new MainClass ().Foo (9);

	void Foo (int arg)
		Func<int> a = () => {
			return arg; // Try to set a breakpoint here

		a ();
Comment 1 Jeffrey Stedfast 2012-02-22 14:32:31 UTC
The problem seems to be that there is no location info for line 13 (the line with "return arg").

Should I be placing the bp on line 12?

Note to self: make sure the fix for this doesn't break bug #3519 or bug #3238
Comment 2 Jeffrey Stedfast 2012-02-22 14:38:03 UTC
Hmmm, no, putting the bp on line 12 sets a bp on the assignment, not on the execution of the anonymous func.
Comment 3 Marek Safar 2012-02-23 07:37:26 UTC
There is correct location info for lines 13-15

Relevant sections from mdb file

    <method token="0x6000002">
        <entry il="0xd" row="11" file_ref="1" hidden="false" />
        <entry il="0xe" row="12" file_ref="1" hidden="false" />
        <entry il="0x1b" row="17" file_ref="1" hidden="false" />
        <entry il="0x22" row="18" file_ref="1" hidden="false" />
        <entry name="a" il_index="1" scope_ref="0" />
      <scopes />

    <method token="0x6000005">
        <entry il="0x0" row="13" file_ref="1" hidden="false" />
        <entry il="0x1" row="14" file_ref="1" hidden="false" />
        <entry il="0xd" row="15" file_ref="1" hidden="false" />
      <locals />
      <scopes />
Comment 4 Marek Safar 2012-02-23 07:38:41 UTC
Note: for the info above I moved anonymous method { to new line
Comment 5 PJ 2012-02-29 17:17:02 UTC
I was about to file a new bug, but I think this might be related.

We have a debugging test app (actually part of MT tests) and we are seeing an issue where breakpoints placed inside delegates are resolving incorrectly. You can set them before you run it, but they jump to different lines. Once the app is running, setting a breakpoint on those lines will result in a breakpoint being added to the other line.


Theres another issue in that cast with the 'step over' not actually stepping over. Thoughts on that too?

Seen on:
MT 5.2.6
Mono 2.10.9

Not seen on:
MT 5.2.6
Mono 2.10.8
Comment 6 Mikayla Hutchinson [MSFT] 2012-03-01 18:12:46 UTC
That's a regression caused by these changes to how the debugger "adjusts" invalid breakpoints to the closest valid location. The problem is that when scanning the containing type, it sees a "gap" in the location information where the anonymous delegate would be, and adjusts the breakpoint to the beginning of the gap. The anonymous delegate is on another type that has not yet been loaded, so it's not possible for MD to find its location from sdb at that time.

The best solution is probably for MD to use its information about "user assemblies". When a breakpoint does not resolve exactly, MD would attempt to load the mdb. It would perform the adjustment only if it could load the mdb and no other method in the mdb had a closer match.
Comment 7 Jeffrey Stedfast 2012-03-02 15:31:44 UTC
this is now fixed in master and backported to 2.8.8-series
Comment 8 lindsey.driscoll 2012-03-20 17:48:41 UTC
Verified fixed in git revision 862a2925f863d93cba4617fb9645af46651b8739 2.8.8-series
Comment 9 Lluis Sanchez 2012-04-18 14:22:06 UTC
I can still reproduce the problem. Using the XWT project (https://github.com/mono/xwt), I can reproduce it in the following locations:

Xwt.Gtk/Xwt.GtkBackend/WidgetBackend.cs:598, 653, 686, 705, 747
Comment 10 Jeffrey Stedfast 2012-04-18 17:43:34 UTC
grrrr, this got broken when someone brought in an old (unfixed) Mono.CompilerServices.SymbolWriter