Start new debug sessions from within debugger

[zobo]

Hello. I currently do feature development on the PHP debugger https://github.com/xdebug/vscode-php-debug and have the following question/request.

The DBGP debug protocol that is used to debug languages like PHP, Python, AutoHotkey has a "connect back" concept where the DEBUGGER LISTENS and the DEBUGEE CONNECTS to it. In a typical PHP setup it could, and usually does mean, that for each page-load the PHP runtime makes a connection to the debugger.
The debugger should offer the user a separate debug session for each connection received.

What we are currently doing is that we present these individual debugee connections as threads in the currently running debug session.

Currently each debug session must be initiated form vscode side. Is there a way it could be achieved that when the extension receives a valid DBGP debug connection it somehow starts a new DebugSession and passes the connected socket over to that one?

Thank you.

[weinand]

@connor4312 this feature request seems to be related to what you are doing in js-debug.
I think we should add support for this in DAP. What do you think?

[connor4312]

Interesting the DBGP protocol is 'push only' for session instantiation. I think this makes sense, right now js-debug needs to call startDebugging in VS Code and short circuit the configuration logic for child sessions. I wonder if any adapter needs launch configs for child sessions, since children can only be created programmatically.

js-debug has a separate bundle for VS that makes a custom DAP request to trigger a child session, and nvim-dap had trouble trying to set it up because of the need for special child-session logic. Adding a protocol-level feature would make js-debug more reusable.

[zobo]

Thanks for the hints. As far as I understand the behavior could be achieved by having two parts in the implementation:

1. The DAP implementation extending vscode-debugadapter.DebugSession. This part is defined under package.json contributes.debggers and is launched in a separate extension host.
2. The extension part (defined in package.json main and registered through activate()).

So when a "listen" (we'd probably abuse "attach") type of debug session would be started

1. vscode starts DAP implementation and we start a listen socket for dbgp
2. when a dbgp connection is received we store it globally and then we fire a custom even from DAP and catch it with help of onDidReceiveDebugSessionCustomEvent (similar to https://github.com/microsoft/vscode-node-debug/blob/034f91bb445e24f430da461a80be7493108d0b66/src/node/extension/autoAttach.ts#L50)
3. we build a special config passing socket information received through custom even and pass it back via vscode.debug.startDebugging (like https://github.com/microsoft/vscode-node-debug/blob/034f91bb445e24f430da461a80be7493108d0b66/src/node/extension/autoAttach.ts#L143)
4. back in DAP implementation we extract the socket information, get the globally stored socket and start normal debugging

This way we end up with two sessions. One responsible for listening, another for the active active connection.
This would be really nice and would mimic how I implement my first DBGP debug client.
There the action of "listen for dbgp/stop listening for dbgp" was separate from "stop/disconnect current active dbgp session".

My question is, will passing the parentSession like this vscode.debug.startDebugging(folder, config, parentSession); ensure the new DAP session will start in the same extension host and so can access the native socket?

Now, if there were a simpler option, even better :)

Thanks!

[connor4312]

Your proposed approach is very similar to what the JavaScript debugger does. As far as I know any given extension can be activated in at most one extension host, so that would work.

[weinand]

@zobo please note that vscode-debugadapter.DebugSession is an implementation detail of a JS/TS library for DAP. It is not a DAP concept. The same is true for VS Code extension API like vscode.debug.startDebugging(...).

We should try to come up with a proposal for a language-neutral DAP addition (and we probably should move the discussion to debug-adapter.protocol).

[zobo]

Hi @weinand. I understand, the question was specific to vscode and so I use the term DAP in this context, as you pointed out.
As far as I researched the "debug adapter protocol" setting up a child session seemed a bit out of scope and more depending on the IDE (DAP consumer) plumbing. However providing a concept for it in the protocol itself would be great. I will also open an issue there and we'll see if we come up with a solution.

[zobo]

Hello @connor4312.
I have tried to implement separate debug sessions as described and while in development context it worked ok. But not in production.

What I do is:

1. register an extension with activationEvents: onDebug
2. Start a debug session type "launch" where I open a listening socket on port 9003
3. When a connection is established, I save this connection into a static variable and send a custom event, containing an ID of that connection in the static map.
4. The extension part has a onDidReceiveDebugSessionCustomEvent and then proceeds to call vscode.debug.startDebugging(undefined, config, event.session) where config is the same config of the initial session, but with request set to attach and that connection ID passed with the config object
5. the adapter implementation receives an attachRequest with said connection ID. It looks up the static variable, gets the actual connection/socket object and continues to handle that as in a normal debug session.

As long as I am developing the debug adapter and it's running in one debuggable processes and vscode connects to it via debugServer: 4711 directive, all works fine. But when I let vscode start the adapter process it starts a new one for each startDebugging call.
Thus leading to the new adapter not being able to access the native socket object....

Is there any way to request vscode to reuse the adapter process?

Thanks!

[zobo]

Ok, I should have just RTFM: https://code.visualstudio.com/api/extension-guides/debugger-extension. Doc here explains how using DebugAdapterDescriptorFactory I can manipulate where and how the adaptor exists.

[weinand]

@zobo yes, the DebugAdapterDescriptorFactory will be your friend...

[connor4312]

Let's merge this into microsoft/debug-adapter-protocol#79. Adoption in VS Code can be tracked in #160169.