New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug toolbar buttons disabled #58327

Closed
testforstephen opened this Issue Sep 10, 2018 · 19 comments

Comments

Projects
None yet
7 participants
@testforstephen

testforstephen commented Sep 10, 2018

VSCode: Version 1.27.1 (1.27.1) 5944e81
Platform: macOS/ubuntu

When the user is stepping over his program, the CALL STACK view shows the program is PAUSED ON STEP, but the debug toolbar buttons are disabled. See the following screenshot.
screen shot 2018-09-10 at 9 20 53 am

This issue is stably reproduced on macOS/ubuntu. Also there is some user reporting it occurs in Windows 10 sometimes, and downgrade to 1.26.0, the issue disappear.

@tanneraphid34

This comment has been minimized.

Show comment
Hide comment
@tanneraphid34

tanneraphid34 Sep 12, 2018

image
The issue is coming in Win10 as well.
I'm using vscode 1.27 on Win10 Enterprise(Version 1607, build 14393.2430)

tanneraphid34 commented Sep 12, 2018

image
The issue is coming in Win10 as well.
I'm using vscode 1.27 on Win10 Enterprise(Version 1607, build 14393.2430)

@Sindisil

This comment has been minimized.

Show comment
Hide comment
@Sindisil

Sindisil Sep 13, 2018

Seeing this when attempting to debug a Java program using 1.27.2 on Windows 10. Essentially, debugging Java doesn't work at all. Reverting to VSCode 1.26 works around the issue for me as well for the time being.

Sindisil commented Sep 13, 2018

Seeing this when attempting to debug a Java program using 1.27.2 on Windows 10. Essentially, debugging Java doesn't work at all. Reverting to VSCode 1.26 works around the issue for me as well for the time being.

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 17, 2018

@isidorn Any updates about this bug?

testforstephen commented Sep 17, 2018

@isidorn Any updates about this bug?

@isidorn

This comment has been minimized.

Show comment
Hide comment
@isidorn

isidorn Sep 17, 2018

Contributor

@testforstephen I was on vacation, sorry for the slow response.
First of all can you reproduce this with the latest vscode insiders?

Contributor

isidorn commented Sep 17, 2018

@testforstephen I was on vacation, sorry for the slow response.
First of all can you reproduce this with the latest vscode insiders?

@Sindisil

This comment has been minimized.

Show comment
Hide comment
@Sindisil

Sindisil Sep 17, 2018

Not sure if @testforstephen can repro with latest vscode insiders, but I just updated my vscode insiders install, and it does indeed still repro.

Sindisil commented Sep 17, 2018

Not sure if @testforstephen can repro with latest vscode insiders, but I just updated my vscode insiders install, and it does indeed still repro.

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 18, 2018

@isidorn yes, this issue can be easily reproduced in 2018-09-17 windows insider version.

testforstephen commented Sep 18, 2018

@isidorn yes, this issue can be easily reproduced in 2018-09-17 windows insider version.

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Sep 18, 2018

Member

Any idea why this problem only affects Java debugging? We have no other reports of this.

Member

weinand commented Sep 18, 2018

Any idea why this problem only affects Java debugging? We have no other reports of this.

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 18, 2018

@weinand In Java Debugger, we took asynchronous programming. One thread to handle the DA request, another thread to report event from JVM in real time. That means when the user is stepping, the possible DA sequence is [ContinueRequest, New StoppedEvent, ContinueResponse], or [ContinueRequest, ContinueResponse, New StoppedEvent]. I guess this may be the reason.

testforstephen commented Sep 18, 2018

@weinand In Java Debugger, we took asynchronous programming. One thread to handle the DA request, another thread to report event from JVM in real time. That means when the user is stepping, the possible DA sequence is [ContinueRequest, New StoppedEvent, ContinueResponse], or [ContinueRequest, ContinueResponse, New StoppedEvent]. I guess this may be the reason.

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Sep 18, 2018

Member

Ok, I see.
DAP requires that the ContinueResponse is received before the resulting StoppedEvent.
You can use any programming technique in the implementation of your DA. But you'll have to make sure that the order of events, requests, and responses remains logical. So if a stop event arrives before the corresponding continue request has finished, VS Code will get confused.

Could you try whether it makes a difference if you implement the step and continue requests like this:

protected continueRequest(response: ContinueResponse, args: ContinueArguments): void {
        if (args are ok) {
             this.sendResponse(response);
        } else {
             this.sendErrorResponse(response);
        }
	this._runtime.continue();   // do the continue (which may result in a StoppedEvent that arrives after the continueResponse).
}

And you will have to make sure that all DAP communication is not affected by thread scheduling. So with the above implementation of continueRequest it should not be possible that the StoppedEvent is sent from your DA before the continueResponse.

I assume that nothing has changed on your side, right?
@isidorn did we change anything in that area in 1.27.1?

Member

weinand commented Sep 18, 2018

Ok, I see.
DAP requires that the ContinueResponse is received before the resulting StoppedEvent.
You can use any programming technique in the implementation of your DA. But you'll have to make sure that the order of events, requests, and responses remains logical. So if a stop event arrives before the corresponding continue request has finished, VS Code will get confused.

Could you try whether it makes a difference if you implement the step and continue requests like this:

protected continueRequest(response: ContinueResponse, args: ContinueArguments): void {
        if (args are ok) {
             this.sendResponse(response);
        } else {
             this.sendErrorResponse(response);
        }
	this._runtime.continue();   // do the continue (which may result in a StoppedEvent that arrives after the continueResponse).
}

And you will have to make sure that all DAP communication is not affected by thread scheduling. So with the above implementation of continueRequest it should not be possible that the StoppedEvent is sent from your DA before the continueResponse.

I assume that nothing has changed on your side, right?
@isidorn did we change anything in that area in 1.27.1?

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 18, 2018

The same logic works previously in a long time, we didn't change that part code recently. But i'll do some experiment on your suggestion.

testforstephen commented Sep 18, 2018

The same logic works previously in a long time, we didn't change that part code recently. But i'll do some experiment on your suggestion.

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 18, 2018

through the screenshot we pasted above, apprently vscode knows the thread is paused on step, because the CALL STACK view/variable/code pointer are rendered correctly, except that the debug buttons don't respect the same status.

Besides, i did a quick test via keeping the stoppedEvent sent after StepResponse, it can mitigate the status issue for single thread. But the debug buttons still have the inconsistent status issue for multiple threads case.
For example, there are multiple threads suspending on breakpoints, continue one thread to make it's becoming running, then switch to the other thread, it's CALL STACK status/code pointer both are stopping at the breakpoint, but the step buttons are disabled. Just like the bug described. Looks like this is a status management issue that should be investigated at vscode side.

testforstephen commented Sep 18, 2018

through the screenshot we pasted above, apprently vscode knows the thread is paused on step, because the CALL STACK view/variable/code pointer are rendered correctly, except that the debug buttons don't respect the same status.

Besides, i did a quick test via keeping the stoppedEvent sent after StepResponse, it can mitigate the status issue for single thread. But the debug buttons still have the inconsistent status issue for multiple threads case.
For example, there are multiple threads suspending on breakpoints, continue one thread to make it's becoming running, then switch to the other thread, it's CALL STACK status/code pointer both are stopping at the breakpoint, but the step buttons are disabled. Just like the bug described. Looks like this is a status management issue that should be investigated at vscode side.

@bastlaca

This comment has been minimized.

Show comment
Hide comment
@bastlaca

bastlaca Sep 19, 2018

I can also repeat this problem:

  1. Start (tomcat) debuggint
  2. Click step over(F10)
    After that Continue(F5) will turn into Pause(F6) and central buttons will be grays.

I use:

  • VS Code 1.27.2
  • Linux Mint 19

bastlaca commented Sep 19, 2018

I can also repeat this problem:

  1. Start (tomcat) debuggint
  2. Click step over(F10)
    After that Continue(F5) will turn into Pause(F6) and central buttons will be grays.

I use:

  • VS Code 1.27.2
  • Linux Mint 19
@SGI495

This comment has been minimized.

Show comment
Hide comment
@SGI495

SGI495 Sep 19, 2018

I (and multiple colleagues) can also reproduce this issue.

Same description: Debugger stops on breakpoints, I step over once and then the thread is paused on step but debug controls are deactivated.

Let me know if I can try anything or send any info to help nail down the issue.

  • VSCode 1.27.2
  • Windows 10

SGI495 commented Sep 19, 2018

I (and multiple colleagues) can also reproduce this issue.

Same description: Debugger stops on breakpoints, I step over once and then the thread is paused on step but debug controls are deactivated.

Let me know if I can try anything or send any info to help nail down the issue.

  • VSCode 1.27.2
  • Windows 10
@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 19, 2018

we submit a fix on java-debug side to fix the StoppedEvent sequence issue, now the debug buttons work well for the single thread scenario. But if it's multiple thread scenario, switching to other thread, VS Code probably lose the old thread's debug status. See the gif.
debugbuttons

testforstephen commented Sep 19, 2018

we submit a fix on java-debug side to fix the StoppedEvent sequence issue, now the debug buttons work well for the single thread scenario. But if it's multiple thread scenario, switching to other thread, VS Code probably lose the old thread's debug status. See the gif.
debugbuttons

@SGI495

This comment has been minimized.

Show comment
Hide comment
@SGI495

SGI495 Sep 19, 2018

@testforstephen I just saw the comment in another issue about the debugger fix. I've updated to version 0.13 of the Debugger for Java and it works again for me now. Thanks!

SGI495 commented Sep 19, 2018

@testforstephen I just saw the comment in another issue about the debugger fix. I've updated to version 0.13 of the Debugger for Java and it works again for me now. Thanks!

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Sep 19, 2018

Member

@isidorn since this problem already occurred in 1.27 it is not related to my changes for 1.28

Member

weinand commented Sep 19, 2018

@isidorn since this problem already occurred in 1.27 it is not related to my changes for 1.28

@bastlaca

This comment has been minimized.

Show comment
Hide comment
@bastlaca

bastlaca Sep 19, 2018

It works again. Thank you.

bastlaca commented Sep 19, 2018

It works again. Thank you.

@isidorn isidorn closed this in c805df9 Sep 19, 2018

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Sep 20, 2018

Verified the multiple threads case, it works in the 2018-09-20 windows insider.

testforstephen commented Sep 20, 2018

Verified the multiple threads case, it works in the 2018-09-20 windows insider.

@isidorn

This comment has been minimized.

Show comment
Hide comment
@isidorn

isidorn Sep 20, 2018

Contributor

@testforstephen thanks a lot for verifiing, adding verified label

Contributor

isidorn commented Sep 20, 2018

@testforstephen thanks a lot for verifiing, adding verified label

@isidorn isidorn added the verified label Sep 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment