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

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.

@isidorn Any updates about this bug?

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

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

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

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

@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.

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?

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.

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.

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

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

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.

@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!

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

It works again. Thank you.

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

@testforstephen thanks a lot for verifiing, adding verified label