Bug 5249 - Breakpoints on { in empty lambda ends in wrong place
Summary: Breakpoints on { in empty lambda ends in wrong place
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-05-22 16:14 UTC by Eric Maupin
Modified: 2013-09-16 15:37 UTC (History)
8 users (show)

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


Attachments
Requested assembly (5.50 KB, application/x-msdownload)
2012-09-13 16:53 UTC, Eric Maupin
Details
Requested mdb (560 bytes, application/octet-stream)
2012-09-13 16:53 UTC, Eric Maupin
Details
Requested pdb (15.50 KB, application/octet-stream)
2012-09-13 16:53 UTC, Eric Maupin
Details
Repro project (506.72 KB, application/octet-stream)
2012-09-13 19:22 UTC, Eric Maupin
Details
patch for pdb2mdb (1.02 KB, patch)
2012-09-15 17:00 UTC, Zoltan Varga
Details
pdb2mdb.exe (60.00 KB, application/x-msdownload)
2012-09-17 11:35 UTC, Zoltan Varga
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 GitHub or Developer Community 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:
RESOLVED FIXED

Description Eric Maupin 2012-05-22 16:14:50 UTC
In Visual Studio using 4.2-series 804357b4

Action<string> a = s =>
{ // Breakpoint here

};

a ("foo");


Visually where the debugger will end up upon hitting the breakpoint is somewhere far below the actual breakpoint.
Comment 1 Jonathan Pobst 2012-05-23 11:37:14 UTC
I can repro this in MD 3.0.1 when debugging against the Mono runtime.  When debugging against the .Net runtime, the breakpoint stops as expected.
Comment 2 Jeffrey Stedfast 2012-06-01 16:15:57 UTC
This works fine now (breakpoint lands on the };
Comment 3 Jeffrey Stedfast 2012-06-01 16:33:37 UTC
n/m, I missed that this was on Windows in VS and M4A

It works fine on Mac w/ mcs.

Apparently in both cases listed above where it fails, it was built using csc and not mcs.

I don't know what the bug is, but clearly it's not MonoDevelop since VS is getting it wrong, too.
Comment 4 Jeffrey Stedfast 2012-06-01 16:35:12 UTC
possibly a mismatch in how csc and mcs embed line info?
Comment 5 Eric Maupin 2012-09-13 16:53:26 UTC
Created attachment 2531 [details]
Requested assembly
Comment 6 Eric Maupin 2012-09-13 16:53:40 UTC
Created attachment 2532 [details]
Requested mdb
Comment 7 Eric Maupin 2012-09-13 16:53:56 UTC
Created attachment 2533 [details]
Requested pdb
Comment 8 Zoltan Varga 2012-09-13 19:19:26 UTC
Can you attach the source file as well ?
Comment 9 Eric Maupin 2012-09-13 19:22:59 UTC
Created attachment 2534 [details]
Repro project
Comment 10 Zoltan Varga 2012-09-13 22:32:44 UTC
I don't have VS + m4a setup, so I can't try that out, but did try out the following test case:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
using System;

public class Tests
{
	public static void Main (String[] args) {
		Action<string> a = s =>
			{
			};
		a ("foo");
	}
}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

This seems to work for me with both mcs and with csc. However, the line number info for the csc compiled anon method looks like this:

Line number table for method Tests:<Main>b__0 (string):
IL0 -> z:\line.cs:7 -1
IL1 -> z:\line.cs:16707566 -1
IL1 -> z:\line.cs:16707566 -1

while for the mcs version, it looks like this:

Line number table for method Tests:<Main>m__0 (string):
IL0 -> /Users/vargaz/git/mono/mono/mini/line.cs:7 -1
IL0 -> /Users/vargaz/git/mono/mono/mini/line.cs:8 -1
IL0 -> /Users/vargaz/git/mono/mono/mini/line.cs:8 -1

The line numbers in the first one look pretty strange, so it might be a problem in pdb2mdb.
Comment 11 Zoltan Varga 2012-09-15 16:59:49 UTC
Could you try the attached patch ?
Comment 12 Zoltan Varga 2012-09-15 17:00:26 UTC
Created attachment 2541 [details]
patch for pdb2mdb
Comment 13 Zoltan Varga 2012-09-17 11:35:00 UTC
Created attachment 2557 [details]
pdb2mdb.exe
Comment 14 Jonathan Pryor 2012-09-28 16:04:21 UTC
Patch in Comment #12 applied in Mono for Android master/9319974b.
Comment 15 Zoltan Varga 2012-09-28 16:48:35 UTC
Did that fix the problem ?
Comment 16 Jonathan Pryor 2012-12-07 16:52:02 UTC
@Zoltan: ermau tells me that it didn't fix the problem, and that when the breakpoint is triggered the debugger is on the '}' line, not the '{' line.
Comment 17 Eric Maupin 2012-12-07 18:06:24 UTC
Sometimes, sometimes it's still the bottom of the file.
Comment 18 Miguel de Icaza [MSFT] 2013-01-09 14:47:21 UTC
Eric,

When you say "Sometimes", does it mean that it happens randomly, so every time you restart the app, you get it at a random place, or that some scenarios work as expected, and others do not?

I hope it is the second case, and if it is the second case, can you provide a repro for the cases where this is failing?
Comment 19 Eric Maupin 2013-01-09 15:15:16 UTC
(In reply to comment #18)
> Eric,
> 
> When you say "Sometimes", does it mean that it happens randomly, so every time
> you restart the app, you get it at a random place, or that some scenarios work
> as expected, and others do not?

It never works as expected that I've been able to find. Sorry I was not clear in comment #17, I was responding to #16. I once saw it move to the } instead of {, but since then I've only ever been able to reproduce it moving to the end of the file.

> I hope it is the second case, and if it is the second case, can you provide a
> repro for the cases where this is failing?

The attached repro still fails by moving the debugger to the end of the file. Reconfirmed with 646a244c22ed4b9ec361a2445ddef90b8c4c1793
Comment 20 Zoltan Varga 2013-01-10 20:46:27 UTC
I tried a sample m4a application, and the line number info in the .mdb file looks like this:

[Line 1:22:0]
[Line 1:16707566:1]

Which means that the patch in comment #12 was probably not used when generating the .mdb file, or it does not work for some reason.
Comment 21 Zoltan Varga 2013-01-10 21:05:09 UTC
Looking at the disassembly of Novell.MonoDroid.Build.Tasks.dll from the mono-android-4.4.55.104956787.msi I used, it doesn't contain the patch.
Comment 22 Jonathan Pryor 2013-01-10 21:48:21 UTC
@zoltan: 4.4.x doesn't have the patch applied, master/4.5.x does.
Comment 24 Zoltan Varga 2013-01-12 08:12:56 UTC
Eric: can you reproduce with 4.4.x or with master ?
Comment 25 Eric Maupin 2013-01-12 11:22:58 UTC
(In reply to comment #24)
> Eric: can you reproduce with 4.4.x or with master ?
Both.
Comment 26 Zoltan Varga 2013-01-14 08:28:37 UTC
I can't reproduce this with m4a 4.5.180. The cursor is at the correct line, and the line number info seems correct as well.
Comment 27 Eric Maupin 2013-01-14 09:28:15 UTC
(In reply to comment #26)
> I can't reproduce this with m4a 4.5.180. The cursor is at the correct line, and
> the line number info seems correct as well.

Interesting. I had tried with 4.5.175 previously and still got the bug. I just retried with .180 and am getting the expected behavior.
Comment 28 Zoltan Varga 2013-01-14 12:51:12 UTC
Perhaps the patch which fixed this needs to be backported to the stable verson.
Comment 29 Zoltan Varga 2013-09-16 15:37:26 UTC
-> FIXED.