Vscode: Debugger unable to attach to process

[Wenzil]

• VSCode Version: 1.3.0
• OS Version: OS X Yosemite 10.10.4

Steps to Reproduce:

1. Open VSCode code .
2. Configure launch configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to node",
      "type": "node",
      "request": "attach",
      "address": "localhost",
      "port": 3000,
      "restart": false
    }
  ]
}

1. Launch node server listening on port 3000 node ./index.js
2. Press F5 to launch the debugger

The debugger fails to attach to the node process with no error message. If I change the port in the launch to configuration to the default port (5858), I get the following error message:

Cannot connect to runtime process (timeout after 10000 ms).

//index.js
'use strict';

const http = require('http');
const port = 3000;

const server = http.createServer(function(request, response) {
  response.end('Hello VSCode!');
});

server.listen(port, function() {
  console.log(`Listening on http://localhost:${port}`);
});

[clarkio]

I don't believe you can use the actual node process to debug against. You typically have to run:

node --debug ./index.js

This will spin up a debugger process and on the default port of 5858. This is what VSCode will use as a default for the Attach configuration.

Once you run your node script that way, change the port in your custom configuration to 5858 and then press F5. It will attach to the debugger process which is associated to the runtime process using your code. You'll be able to step through your code from there whenever a request is sent to your server on port 3000.

Node.js Debugger Documentation

[Wenzil]

Ah, thanks for the explanation! Very helpful. How does this relate to this change in the the 1.3 update though?

https://code.visualstudio.com/updates#_nodejs-debugging

I assumed it meant the --debug flag was no longer needed. Is it not the case?

[clarkio]

@Wenzil oh cool, I did not see that new feature. Yea I think you assumed correctly. Looks like the difference there is you do not specify port, but instead specify the processId your Node.js app is running on in the host machine. VSCode will prompt you to select the process when you press F5.

Trying this out I ran the following:

$ node index.js
Listening on http://localhost:3000

Then in VSCode, using the default Attach to Process configuration, pressed F5 which resulted in being prompted to select a node process:

I left the default port of 5858 in the configuration (changing it to 3000 will not work)

Selecting that process 9287 (highlighted in blue), VSCode was able to attach to the process creating its own debugger process. Console/Terminal ends up showing the following:

$ node index.js
Listening on http://localhost:3000
Starting debugger agent.
Debugger listening on port 5858

Hope this helps. Let me know how it goes for you and if that works I think it should resolve this issue.

[Wenzil]

Neat! It works on my Windows 10 machine at home. I'd like to test that it can attach to a remote server process too. I will test that on monday at work.

[weinand]

@clarkio thanks for jumping in and explaining nicely how attach to port and attach to process work.

[Wenzil]

Am I right in thinking it's not possible to attach to a remote process using the process picker?

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to remote process",
      "type": "node",
      "request": "attach",
      "address": "my-remote-host.com",
      "processId": "${command.PickProcess}",
      "port": 5858,
      "sourceMaps": false,
      "outDir": null
    }
  ]
}

The process picker does not find any process. Which makes sense since no sane remote host lists its running processes publicly I presume.

Would it work if I knew the process id and used that instead of the PickProcess command?

[jmandzik]

@Wenzil I had the same thought. I tried explicitly setting the PID I know is running on my remote host (and verified firewall was open, etc). It fails immediately with Error: kill ESRCH:

No process or process group can be found corresponding to that specified by pid

Makes me think it's not able to attach to remote processes; by design or bug I'm not sure. Works great locally, but this line in the release notes got me all excited:

Node.js debugging now supports attaching to a Node.js process that has not been started in debug mode. This can be useful if you need to debug a production server that cannot always run in debug mode for performance reasons.

[weinand]

Of course, attaching to a process by pid (process id) is only possible on localhost. How should VS Code be able to list the processes on a remote system with unknown OS and no rights to list processes? Attaching by pid works by sending a SIGUSR signal to the process. Sending a signal to a process on a remote host would require that you are able to login to that system.

However, you can attach to a remote node.js process by using a hostname and a port (because that works via TCP/IP and across different OSes).

And you can even send the SIGUSR signal on the remote system to node.js (to bring it into debug mode), and then connect to node.js from VS Code running on a different system with hostname and a port. (If you know a portable way to send signals remotely please let me know; I'm accepting PRs ;-)

@Wenzil yes, instead of ${command.PickProcess}you can specify the process id (as a string). The picker is just a command that returns a pid.

[Wenzil]

I'm not able to attach to a remote host using a hostname and port either, I will open a new issue. Thanks guys!

[weinand]

@Wenzil but you did start node with either --debug or --debug-brk and the node version you are using is > 5.0?

[Wenzil]

Yes, node was started using --debug, however node version is 4.4.5. Should be supported according to https://code.visualstudio.com/docs/editor/debugging though?

Here's my launch configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to remote host",
      "type": "node",
      "request": "attach",
      "address": "my-remote-host.com", //also tried with IP address
      "port": 5858
    }
  ]
}

[Wenzil]

My coworker is able to attach to the remote node process using Webstorm's debugger, but no dice with VSCode on my side

[weinand]

@Wenzil you are right, node > 4.0 already supported remote debugging.
What is the error message you are getting?

[Wenzil]

I'm not getting any error message, and I just realized that I'm able to write javascript in the REPL. I can even see it outputs to our logstash correctly. So it's attached to the process, but I can't put any breakpoints, and don't see the callstack when I pause.

Correction: I can put breakpoints, but they have no effect, as if the source I'm seeing is only the local source.

[weinand]

@Wenzil since you are remote debugging, you have to set "localRoot" and "remoteRoot" in your launch config if path names on both systems are not identical.
Please see "Remote Debugging Node.js" section in https://code.visualstudio.com/docs/editor/debugging.

[Wenzil]

I'm not able to configure it properly. Still haven't got breakpoints and inspection to work. Does it ever make sense to use something other than "${workspaceRoot}" in localRoot?

As for remoteRoot, I entered the absolute file path of the project root on the remote host.

According to the "Remote Debugging Node.js" section in your link, I should see a read-only version of the debugged source, but what I'm seeing is the local source which is editable.

[weinand]

"${workspaceRoot}" for localRoot makes perfect sense. That's the default anyway.
'absolute file path of the project root on the remote host' for remoteRoot sounds correct.

You are not using source maps, correct?
If you are adding a 'debugger' statement (instead of a breakpoint) to your source, does it make a difference?

[Wenzil]

No source maps, should I add the 'debugger' statement on my local source, or on the remote host?

[Wenzil]

I found the issue! There is a symbolic link in the remoteRoot filepath I was using. /opt/myproject/current points to the last deployed build. When I use the actual file path /opt/myproject/20160705212654, breakpoints start working.

That means I will have to update my launch configuration to point to the new remoteRoot every time I deploy a new build though.

Here's a feature request: support symbolic links in remoteRoot :)

[weinand]

hmmm, VS Code will have a hard time to understand that the remote system uses a symbolic link. VS Code can only talk to the remote node; it does not have access to the file system.