Bug 3417 - Step into line which is not executed
Summary: Step into line which is not executed
Status: RESOLVED FEATURE
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-02-13 08:03 UTC by Marek Safar
Modified: 2017-07-11 22:13 UTC (History)
5 users (show)

Tags:
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 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 FEATURE

Description Marek Safar 2012-02-13 08:03:02 UTC
using System;
using System.Collections.Generic;

class C
{
	public static void Main ()
	{
		var c = new C ();
		foreach (var a in c.Iter_1 ())
		{
		}
	}
	
	IEnumerable<int> Iter_1 ()
	{
		yield return 1;	// Set a breakpoint here and F11 (step into) few times
	}	// debugger continue here even if this IL code is not executed in this run
}

Note: requires mono master
Comment 1 Jeffrey Stedfast 2012-02-13 09:30:04 UTC
I think this is actually runtime...
Comment 2 Zoltan Varga 2012-02-13 13:51:17 UTC
The runtime is actually executing the MoveNext method, whose line number info references those lines in the source:

Line number table for method C/<Iter_1>c__Iterator0:MoveNext ():
IL21 -> /home/zovarga/work/Hello/Hello/Main.cs:15
IL22 -> /home/zovarga/work/Hello/Hello/Main.cs:16
IL3d -> /home/zovarga/work/Hello/Hello/Main.cs:17
IL3d -> /home/zovarga/work/Hello/Hello/Main.cs:17

So what happens here seems perfectly normal.
Comment 3 Marek Safar 2012-02-14 11:49:21 UTC
Line table looks like

        <entry il="0x21" row="15" file_ref="1" hidden="false" />
        <entry il="0x22" row="16" file_ref="1" hidden="false" />
        <entry il="0x3d" row="17" file_ref="1" hidden="false" />

0x3d is never reached in this run, so the debugger should not use it's line number. Is this something you can handle in sdb or I have to somehow tell sdb?
Comment 4 Zoltan Varga 2012-02-14 12:00:58 UTC
Currently the runtime uses its own heuristics to compute sequence points, and only uses the line number info to map IL offsets to line numbers. So if the pc is in the MoveNext method, we can't hide this from the user.
Comment 5 Marek Safar 2012-02-14 12:07:44 UTC
I don't want to hide it from the user, I just trying to make it logical. The line is not hit in this run, it's used in second run (you could debug this using F11 from top to bottom to see).

Also when setting the breakpoint at line 17. The breakpoint is hit only once but when using stepping the line is hit twice (it could be more in different case)
Comment 6 Rodrigo Kumpera 2013-09-09 12:02:24 UTC
Any news here?