External debug adapter crashes when launched without redirected stdout

[fwcd]

• VSCode Version: 1.26.0
• OS Version: Windows 10 x64

I am currently developing a Kotlin debug adapter running on JVM.

When launching the external debug adapter with stdout redirected to a file (either using System.setOut() or through java ... > file.txt), everything works fine. When launching the debug adapter without modifications to stdout, VSCode yields this error message:

and prints the following stacktrace to the developer tools console:

/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2386 Error
    at file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2574:609
    at Object.v [as _notify] (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:152:302)
    at Object.enter (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:155:568)
    at n.Class.derive._oncancel._run (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:156:902)
    at n.Class.derive._oncancel._error (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:156:419)
    at file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2574:813
    at t.e.acceptMessage (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2513:968)
    at t.handleData (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2514:804)
    at Socket.<anonymous> (file:///C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2514:300)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20)

This is problematic, because my debug adapter relies on stdio for JSON-RPC.

Although #41190 would certainly be helpful, I could not find any issue that resembles this exact problem.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• "no provider for" error when adding/replacing a workspace folder using a custom FileSystemProvider (#51088)
• Most intellisense/autocomplete does not work anymore (#52689)
• myTree.reveal error when hightlighting multiple lines (#51771)
• Error: Promise did not implement oncancel (#55136)
• Breadcrumbs with new settings editor results in empty window after restart (#54451)

[weinand]

I don't understand what you mean by "When launching the debug adapter without modifications to stdout"?

Usually VS Code launches the debug adapter and then communicates with it through stdin/stdout.
Or you instruct VS Code to use the debug adapter in server mode. In this case VS Code connects to a debug adapter running in server mode and communicates via a socket.

What approach are you using?

[fwcd]

@weinand Sorry, if I expressed myself confusingly. I am using the stdin/stdout approach:

VSCode <=> extension <= JSON stdin/out=> (Kotlin) debug adapter

I have encountered the following scenarios:

• Running the debug adapter without VSCode (in a shell) works fine
• Running the debug adapter with VSCode crashes (see the stacktrace above) - although the debug adapter silently continues to run in the background
  • Even after the crash, I can still successfully attach a JVM debugger to it - the debug adapter just keeps listening on stdio
• Running the debug adapter with VSCode while piping stdout to a file does not crash. I suppose, this is because VSCode will wait forever for a JSON response (because all JSON responses were written to the file instead).

I am having a hard time figuring out the concrete problem, because I have no way of capturing the debug adapter‘s output in a VSCode environment. Whenever I want to see what the debug adapter outputs, I need to redirect stdout - but this will obviously not allow the JSON responses to be read by VSCode.

[weinand]

How exactly do you run the debug adapter with VS Code?
Via a static contribution in the package.json of the extension?

[fwcd]

Using adapterExecutableCommand, thus resolving the path dynamically.

I hit the same problem though, when hardcoding the path using the program attribute in package.json.

[fwcd]

@weinand I did some further experiments and have created a simple executable that simply writes everything from stdin into a file. When launching this, everything VSCode seems to write is:

Content-Length: 313

After the header, nothing happens. Only after I close the VSCode window, it writes:

{"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"kotlin","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"},"type":"request","seq":1}

I suspect that this causes my debug adapter to wait forever for the initialize command.

[fwcd]

According to the Chrome Debugger, the error happens here:

Somehow, the initialize response is not accepted by the VSCode client

[fwcd]

Apparently not a VSCode issue: eclipse-lsp4j/lsp4j#227

[fwcd]

@weinand Thanks for your prompt support anyway.

[weinand]

@fwcd great that you were able to find the issue yourself.

In general I think there are two approaches for debugging the interaction between a debug adapter and VS Code:

• use a protocol trace option if the DA supports it. All node.js based debug adapters have a trace option because the underlying client library supports this. If your DA is Java based and uses some DAP client library and does not support "trace", I suggest that you create a feature request against the library for that.
• debug the DA with a VS Code debugger. Every DA should be able to run in server mode by passing a "--server=12345" argument from the command line. By using this you can run the DA in a VS Code debugger (e.g. Java Debugger in your case). Then you can add a ""debugServer": 12345 attribute to your launch configuration. With this VS Code will not launch a new DA when starting a debug session but instead connect to your server running in the debugger. This will allow you to step through all interactions between the VS Code frontend and the DA.