Debug: setting expression and hit-count at the same time does not hit anything

[bpasero]

Testing #13211

• I run a simple extension with a command
• I defined 2 conditions for when the command gets executed: expression and hit-count

=> the breakpoint is never being hit

I can provide more steps to reproduce but maybe this scenario is not even supported?

[isidorn]

It is supported, if the breakpoint is not being hit it is coming from the adapter, thus assigning to @weinand

[weinand]

Works fine for me. I was using this example:

var i = 0;
for (i = 0; i < 100; i++) {
    console.log(i);
}

As a condition I used i % 10 === 0 and as a hit count % 2

With this the execution stopped for i == 10, 30, 50, 70, ...

@isidorn However, setting both expressions on a breakpoint seems to be a bit fragile. I had to try two times until both expressions stuck to the breakpoint (here it would have helped if the hover would show both expressions see #14359).

[bpasero]

Not sure if related but I was debugging an extension.

[weinand]

I tried my snippet in an extension and still works fine

[rkeithhill]

I have implemented hit count support in the PowerShell extension (well, PR is waiting to be accepted) and in my testing, both the condition and hitCondition come through to the debug adapter. After that, it is up to the debug adapter to do the right thing.

setting both expressions on a breakpoint seems to be a bit fragile.

I noticed this too. You have to hit enter and not just change the value and select the drop down to change from say Expression to Hit Count (or vice versa). If you do the latter, your change doesn't take. But when you press enter to accept a value, the UI goes away. So if you want to set both fields, the UI is a tiny bit tedious.

@weinand What's up with the value you used % 2? The UI says Hit Count but in the protocol it is hitCondition. Looks like %2 is short for hitCount % 2 == 0? For PowerShell I only allow an integer for this (using int.TryParse to pull out that int). Hmm, am I missing an important scenario by only allowing a number? I guess I'm used to Visual Studio's conditional breakpoint taking only numbers e.g.:

I also agree on the hover tip, need to see both conditions. Looks like that has been fixed already. Yay!

[weinand]

@rkeithhill The debug protocol does not specify the syntax of the hit count expression. So you are free to accept and validate whatever you want. For node I'm basically using the same as the xDebug protocol for php. But the node implementation does not yet validate what it receives.

[weinand]

Assigning to @isidorn since the issue at hand seems to be more of an UX problem.

[isidorn]

Closing this as there are no steps and I can not reproduce any of the mentioned issues.
I can always set both hit cound and expression to a breakpoint and the hover now shows that.
I can always hit breakpoints if they have both hit count and condition - also when debugging extensions.

Please reopen if you still see this on your machine and try to find steps - if not ping me and I wlll come to your machines. Thanks

[rkeithhill]

For me, the only issue that exists here is that the dropdown UI does not save the current value when switching between Expression and Hit Count. I know the watermark text says to hit press Enter but I think a fair number or folks will type an Expression, hit the drop down to set the Hit Count, then they press Enter. In this scenario only the Hit Count is accepted. The condition expression is not.

[isidorn]

@rkeithhill got it -> for that I have created the issue #15151

[bpasero]

@isidorn @weinand is it expected that if I define both hit count and expression, the breakpoint is only hit when the hit count expression is met?

Here is my repro:

• simple hello world extension
• breakpoint inside the command handler for hello world
• hit count: 2
• expression: console !== null

=> breakpoint only gets hit when executing the hello world command twice

[isidorn]

This is up to the debug adapter to decide. But from how I understand it both conditions need to be true in order for the breakpoint to be hit.

[weinand]

Sure both conditions need to be true in order to 'break'.