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
This is the step on which the test fails
basically the debugger is breaking on a field when it should not
This is much smaller repro, moving to runtime because this filtering is handled there.
public static void Main(string args)
UninitializedClass.Call();//Breakpoint here and step in
static string DummyCall()
//Should NOT step into this method
//if StepFilter.StaticCtor is set
//because this is part of static class initilization
static string staticField = DummyCall();
public static void Call()
//Should step into this method
I can reproduce with Mono 184.108.40.206 (2017-10/a3943e28cf8)
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?
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
mono-2017-12 is dev 15.7 timeframe
That sounds good. would it be possible to get this in 2017-12?
It has been backported to mono:2017-12 with https://github.com/mono/mono/pull/6634 already.