Bug 59649 - MacDebuggingTest>HeartRateMonitor sample Step Into is not working properly
Summary: MacDebuggingTest>HeartRateMonitor sample Step Into is not working properly
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger (show other bugs)
Version: master
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Alexander Kyte
Depends on:
Reported: 2017-09-21 14:37 UTC by Swati Gangrade
Modified: 2018-02-11 16:30 UTC (History)
8 users (show)

See Also:
Tags: AutomationDefect,bugpool-archive
Is this bug a regression?: ---
Last known good build:


Description Swati Gangrade 2017-09-21 14:37:25 UTC
Description- Instead of Step Into a method, breakpoint is hit on class variable


Jenkins Execution Link – http://xqa-jenkins2.corp.microsoft.com/job/VSMac/job/smoke-15-4/150/testReport/XQA.XS.Tests/MacDebuggingTests/

Executed on - XQA-XS-Sierra-2

Status – Failed

Build Info- Build #150 | 3e37a1db (manifest) (Sep 20, 2017 5:13:34 PM)

Platform Smoke Test » d15-4 build number 92

Github Web- https://github.com/xamarin/release-manifests/commit/3e37a1dbec257287e5e953bb0fb8c1eb42f459ee

Test Report- http://xqa.blob.core.windows.net/gist/TestReport-8fecfe21230d4801b5a4179eb48cb0cf.txt

VSFM Build Info - http://xqa.blob.core.windows.net/gist/log-b3f01fad860e47518f189780af6b4941.txt


Rescheduled Jobs and passed on below bots
Job1- Jenkins Execution Link- http://xqa-jenkins2.corp.microsoft.com/job/VSMac/job/generic/1076/testReport/XQA.XS.Tests/MacDebuggingTests/
Executed on - XQA-XS-Sierra-5
Status – Pass	

Job 2- Jenkins Execution Link- http://xqa-jenkins2.corp.microsoft.com/job/VSMac/job/generic/1067/testReport/XQA.XS.Tests/MacDebuggingTests/
Executed on - XQA-XS-Sierra-7
Status – Pass	


Observation- After Step Into command, execution control goes to the HeartRateClass declared variable "static randomly CBUUID PeripheraUUID=CBUUID.FromPartial (0X180D);"(line number 37)
instead of expected line number 43 i.e. into "ScanForHeartRateMonitors (managers)" 

Expected Result- Debugger should be step into method and breakpoint should be hit on line number 43 
Comment 1 Manish Sinha 2017-09-21 14:39:58 UTC
This is the step on which the test fails

basically the debugger is breaking on a field when it should not
Comment 2 David Karlaš 2017-09-22 08:37:28 UTC
This is much smaller repro, moving to runtime because this filtering is handled there.

using System;

namespace bug59649
    class MainClass
        public static void Main(string[] args)
            UninitializedClass.Call();//Breakpoint here and step in

    class UninitializedClass
        static string DummyCall()
            //Should NOT step into this method
            //if StepFilter.StaticCtor is set
            //because this is part of static class initilization
            return String.Empty;

        static string staticField = DummyCall();
        public static void Call()
            //Should step into this method
Comment 3 Ludovic Henry 2017-10-06 20:25:35 UTC
I can reproduce with Mono (2017-10/a3943e28cf8)
Comment 4 Marek Safar 2018-01-17 19:47:43 UTC
Comment 5 Manish Sinha 2018-01-22 21:14:36 UTC
Is the fix risky enough to bring it in mono-2017-10? If not, is there any release after mono-2017-10 which isn't master?
Comment 6 Ludovic Henry 2018-01-22 22:39:58 UTC
I would say it's a bit risky to bring to mono:2017-10 if it's to get it released as part of d15.5. It will get into mono:2017-12 and later, which could possibly make it into d15.6
Comment 7 Marek Safar 2018-01-23 13:58:30 UTC
mono-2017-12 is dev 15.7 timeframe
Comment 8 Manish Sinha 2018-01-23 15:45:37 UTC
That sounds good. would it be possible to get this in 2017-12?
Comment 9 Ludovic Henry 2018-01-23 21:16:40 UTC
It has been backported to mono:2017-12 with https://github.com/mono/mono/pull/6634 already.

Note You need to log in before you can comment on or make changes to this bug.