Bug 3238 - MD ignores a breakpoint set on no code line
Summary: MD ignores a breakpoint set on no code line
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-06 12:51 UTC by Marek Safar
Modified: 2012-02-16 18:07 UTC (History)
2 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-06 12:51:36 UTC
using System;

class C
	public static void Main ()
		const int i = 9;	// Set a breakpoint here
		Console.WriteLine (i);

The breakpoint is not hit, VS behaviour is that the breakpoint is automatically moved to next line with symbol info
Comment 1 Jeffrey Stedfast 2012-02-06 14:30:50 UTC
MonoDevelop seems to leave the red marker on the "const int" line until the app is run, and then once the breakpoint is resolved, moves it to the CWL.

It seems broken, though, that when we are done debugging, it moves the bp back to the const int decl.
Comment 2 Mikayla Hutchinson [MSFT] 2012-02-06 14:48:38 UTC
That appears to be by design, the debugger keeps track of the "adjustment" so that it can be restored afterwards. But I agree, I'm not sure that's the best thing to do.
Comment 3 Marek Safar 2012-02-06 14:51:08 UTC
That's now what is happening for me with MD master + Mono master. It does not break at all.
Comment 4 Lluis Sanchez 2012-02-08 03:05:49 UTC
The breakpoint adjustment when debugging starts and when it ends is by design. If it does not break after the adjustment, then this is a debugger issue.
Comment 5 Marek Safar 2012-02-08 10:19:14 UTC
I cannot see any adjustment happening.

This is from Application Output

Could not insert breakpoint at '/home/marek/Projects/g2/g2/Main.cs:7': The breakpoint location is invalid. Perhaps the source line does not contain any statements, or the source does not correspond to the current binary
Comment 6 Lluis Sanchez 2012-02-08 10:23:32 UTC
The adjustment only happens when the invalid position is inside a range of valid positions. For example, if you try to place the breakpoint outside of a method, no adjustment will be made.  Maybe in this case that line falls outside the range of valid positions of the method.
Comment 7 Jeffrey Stedfast 2012-02-16 17:41:50 UTC
Okay, so it seems to make a difference having the class in a namespace.

If you wrap a namespace around class C, then this works. Otherwise it says invalid breakpoint and doesn't adjust the breakpoint (and thus no breakpoint is hit).
Comment 8 Jeffrey Stedfast 2012-02-16 17:42:54 UTC
n/m, now it's not working with the namespace either.

What else did I remove??...
Comment 9 Jeffrey Stedfast 2012-02-16 17:45:16 UTC
aha! I had changed the Active Configuration to Mono 2.11

Mono 2.10.9 works as expected.
Comment 10 Jeffrey Stedfast 2012-02-16 18:07:35 UTC
The problem was that Mono 2.10 emitted Location info for line 7, but Mono 2.11 does not.

The fix was to keep scanning locations beyond line 7 until we find something we can break on.