Use DAP's 'startDebugging' request

[weinand]

In order to make js-debug easier to use in other DAP clients, we should try to move VS Code specific "integration particularities" (typically extension code), into the debug adapter itself.

Using the new startDebugging reverse request should make this easier.

For details see: microsoft/debug-adapter-protocol#79

[connor4312]

Depends in part on microsoft/vscode#160169 for testing

[connor4312]

I started this on the dap-server branch, that adds a new standalone pure-DAP server. Still some rough edges though.

[filipdutescu]

will you continue work on it when you get more time, @connor4312, or is it discontinued for now? I would love to use it when available!

[icholy]

@filipdutescu I'm sure @connor4312 would appreciate feedback on the dap-server branch he pushed. Maybe try hooking it up to your editor and see if it works?

[connor4312]

I've implemented this in the linked PR. Releases will have the DAP server included, see the .tar.gz in https://github.com/microsoft/vscode-js-debug/releases/tag/v1.77.0 for an example

The server can be run by extracting the archive and then running ./js-debug/src/dapDebugServer.js.

$ node js-debug/src/dapDebugServer.js --help
Usage: dapDebugServer.js [port|socket path=8123] [host=localhost]

It can also be built into the dist folder by running gulp dapDebugServer in this repo

[mfussenegger]

Could you elaborate on what a client has to do to use it?

Starting the debug adapter via node js-debug/src/dapDebugServer.js works and after the initialization routine the client receives startDebugging with a payload like this:

{
  arguments = {
    configuration = {
      __pendingTargetId = "fb3f50959d426d65d8393287",
      name = "test.js [100212]",
      type = "pwa-node"
    },
    request = "launch"
  },
  command = "startDebugging",
  seq = 9,
  type = "request"
}

Starting another instance of node js-debug/src/dapDebugServer.js and using the launch routine with the provided configuration leads to a timeout on initialize.

How is the client supposed to use the configuration?

debugpy provides a request = "attach" payload in startDebugging, and then the client can open up a TCP connection which works fine.

[connor4312]

Currently the assumption is that the client will connect back to the same debug process instead of launching a new one. But I think I will also support if a client does launch a new DAP instance, as that is a reasonable interpretation of the DAP specification.

[mfussenegger]

Currently the assumption is that the client will connect back to the same debug process

How can it connect back to the same debug process? That doesn't work if the client is implemented in a different runtime and running as a separate process.

But I think I will also support if a client does launch a new DAP instance, as that is a reasonable interpretation of the DAP specification.

As mentioned I tried that and it didn't work. The client receives no response to the initialize of the second process that's started as response to startDebugging.

[connor4312]

The DAP server listens on either a port or socket/pipe. A client can make a new connection to the same port or socket/pipe.

As mentioned I tried that and it didn't work

That's why I used future tense and reopened this issue 🙂

[mfussenegger]

The DAP server listens on either a port or socket/pipe. A client can make a new connection to the same port or socket/pipe.

Oh right, thanks for the pointer. I managed to get it working.

(For others following this issue, here's the configuration: https://github.com/mfussenegger/nvim-dap/wiki/Debug-Adapter-installation#vscode-js-debug)

[icholy]

You guys rock!

[navono]

Does anyone have an example of using dapDebugServer as debugger, VSCode as editor or another editor as client? I've tried VSCode as editor, connected to dapDebugServer, but I can't debug in VSCode.

The following is the launch.json configuration

     {
       "type": "pwa-node",
       "request": "launch",
       "name": "DebugJs",
       "program": "${workspaceFolder}/test.js",
       "stopOnEntry": true,
       "debugServer": 8123
     }

[puremourning]

Is it intentional that there is no dap release for 1.77.1 and 1.77.2 ?

[connor4312]

Yea, technically this will only land in 1.78.0. 1.77.x are recovery releases off 1.77.0 that didn't have them. I made a special build for 1.77.0 so people can start trying it out.

[puremourning]

Yea, technically this will only land in 1.78.0. 1.77.x are recovery releases off 1.77.0 that didn't have them. I made a special build for 1.77.0 so people can start trying it out.

OK great, thanks. Is here the best place to provide feedback? I'm testing it with vimspector this week.

Initial feedback is that I have got it to "work" but simply stepping through a trivial file is extremely slow. Stepping takes like 0.5s (compared to say 0.1s for the legacy vscode-node-debug2 on the same file).

It's entirely possible that's on my side, but I don't see similar problems with other multi-session servers (like debugpy). It looks to me like it's the stackTrace request, which takes about 500ms:

Example:

2023-04-11 ***16:50:37,242*** - DEBUG - debug_adapter_connection.py:202 - 1 - Sending Message: {"command": "stackTrace", "arguments": {"threadId": 0}, "seq": 16, "type": "request"}
2023-04-11 ***16:50:37,748*** - DEBUG - debug_adapter_connection.py:261 - 1 - Message received: {'seq': 131, 'type': 'response', 'request_seq': 16, 'command': 'stackTrace', 'success': True, 'body': {'stackFrames': [{'id': 7, 'name': '<anonymous>', 'line': 3, 'column': 11, 'source': {'name': '/Users/ben/.vim/bundle/vimspector/support/test/node/simple/simple.js', 'path': '/Users/ben/.vim/bundle/vimspector/support/test/node/simple/simple.js', 'sourceReference': 0}, 'presentationHint': 'normal', 'canRestart': True}, {'id': 8, 'name': 'Module._compile', 'line': 1275, 'column': 14, 'presentationHint': 'normal', 'canRestart': True}, {'id': 9, 'name': 'Module._extensions..js', 'line': 1329, 'column': 10, 'presentationHint': 'normal', 'canRestart': True}, {'id': 10, 'name': 'Module.load', 'line': 1133, 'column': 32, 'presentationHint': 'normal', 'canRestart': True}, {'id': 11, 'name': 'Module._load', 'line': 972, 'column': 12, 'presentationHint': 'normal', 'canRestart': True}, {'id': 12, 'name': 'executeUserEntryPoint', 'line': 83, 'column': 12, 'presentationHint': 'normal', 'canRestart': True}, {'id': 13, 'name': '<anonymous>', 'line': 23, 'column': 47, 'source': {'name': 'internal/main/run_main_module', 'path': 'internal/main/run_main_module', 'sourceReference': 700523592, 'presentationHint': 'deemphasize', 'origin': 'Skipped by skipFiles'}, 'presentationHint': 'deemphasize', 'canRestart': True}], 'totalFrames': 7}}

Compared with the old adapter (same file)

2023-04-11 ***16:56:06,456*** - DEBUG - debug_adapter_connection.py:202 - 0 - Sending Message: {"command": "stackTrace", "arguments": {"threadId": 1}, "seq": 13, "type": "request"}
2023-04-11 ***16:56:06,459*** - DEBUG - debug_adapter_connection.py:261 - 0 - Message received: {'seq': 107, 'type': 'response', 'request_seq': 13, 'command': 'stackTrace', 'success': True, 'body': {'stackFrames': [{'id': 1001, 'name': '(anonymous function)', 'source': {'name': 'simple.js', 'path': '/Users/ben/.vim/bundle/vimspector/support/test/node/simple/simple.js'}, 'line': 3, 'column': 11}, {'id': 1002, 'name': 'Module._compile', 'source': {'name': 'loader.js', 'path': '<node_internals>/internal/modules/cjs/loader.js', 'sourceReference': 1045, 'origin': 'read-only core module'}, 'line': 996, 'column': 14}, {'id': 1003, 'name': 'Module._extensions..js', 'source': {'name': 'loader.js', 'path': '<node_internals>/internal/modules/cjs/loader.js', 'sourceReference': 1045, 'origin': 'read-only core module'}, 'line': 1027, 'column': 10}, {'id': 1004, 'name': 'Module.load', 'source': {'name': 'loader.js', 'path': '<node_internals>/internal/modules/cjs/loader.js', 'sourceReference': 1045, 'origin': 'read-only core module'}, 'line': 863, 'column': 32}, {'id': 1005, 'name': 'Module._load', 'source': {'name': 'loader.js', 'path': '<node_internals>/internal/modules/cjs/loader.js', 'sourceReference': 1045, 'origin': 'read-only core module'}, 'line': 708, 'column': 14}, {'id': 1006, 'name': 'executeUserEntryPoint', 'source': {'name': 'run_main.js', 'path': '<node_internals>/internal/modules/run_main.js', 'sourceReference': 1066, 'origin': 'read-only core module'}, 'line': 60, 'column': 12}, {'id': 1007, 'name': '(anonymous function)', 'source': {'name': 'run_main_module.js', 'path': '<node_internals>/internal/main/run_main_module.js', 'sourceReference': 1039, 'origin': 'read-only core module'}, 'line': 17, 'column': 47}], 'totalFrames': 7}}

As you can see, the timestamps in the first request show ~500ms vs in the 2nd request ~3ms

[connor4312]

That should be fixed with #1644. Here's a dap debug server built off main where it's fixed:

dist.zip

[puremourning]

That should be fixed with #1644. Here's a dap debug server built off main where it's fixed:

dist.zip

Thanks!

[connor4312]

FYI for DAP server users: in #1789 I added DWARF debugging support, but this is not included out of the box since the component needed to enable DWARF debugging is ~8x larger than js-debug itself.

If you want to enable this for the DAP server, you will want to install the @vscode/dwarf-debugging npm module such that require('@vscode/dwarf-debugging') works from wherever js-debug's DAP server is running.