Remote debugging not working again

[tinganho]

I'm not sure in which version of VSCode remote debugging broke for me. But I know it broke for perhaps within 2 months.

These are the settings I've been using for a long time before it broke(and they have been working for many months):

        {
            "name": "Attach Remotely",
            "type": "node",
            "request": "attach",
            "port": 6000,
            "address": "localhost",
            "restart": false,
            "sourceMaps": true,
            "outFiles": [
                "${workspaceRoot}/Build/**/*.js"
            ],
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/srv/noelia"
        }

I'm using Docker Compose for development:

services:
  dev.noelia:
    image: ****
    container_name: dev.noelia
    extra_hosts:
      - "dockerhost:$DOCKERHOST"
    volumes:
      - .:/srv/noelia
      - ~/.bash_history:/root/.bash_history
    ports:
      - "3000:3003"
      - "6000:5858"

I'm using Docker for Mac and I have a debugger breaked on entrance. I run a tcpdump to ensure the VSCode can reach the node runtime.

tcpdump -i eth0 port 5858
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:00:11.189204 IP 172.23.0.1.58520 > 4c1a1942b276.5858: Flags [S], seq 2036585880, win 29200, options [mss 1460,sackOK,TS val 5094367 ecr 0,nop,wscale 7], length 0
16:00:11.189259 IP 4c1a1942b276.5858 > 172.23.0.1.58520: Flags [R.], seq 0, ack 2036585881, win 0, length 0

I can confirm it can reach because some packets are showing every time I click on the attach button.

And I'm using Mocha to issue the debug break statement

./node_modules/mocha/bin/mocha ./Build/Source/Tests/RunTests.js --timeout 15000 --colors --full-trace --grep LinksCanNavigateToSameLayout --debug-brk
Debugger listening on 127.0.0.1:5858

There is no outputted error on VSCode (Debug Console) and when I try to attach to it, it loads a bit and then nothing happens the loading indicator disappears. There are no Debug buttons appearing as usual.

I tried to attach locally by running the same command and it works. Just remote debugging (in a Docker container) doesn't work for me.

[tiansivive]

I am also facing this problem at the moment.

I'm running pretty much the exact same configurations: running on a Mac, trying to connect the debugger to node inside docker, no error is shown and the debug control panel just never appears.

Toggling Dev Tools doesn't provide any extra info either, there's no error in the console there.

[mulleady1]

I've been using the VSCode debugger for a Node app on a Mac for a while. We just switched our dev environment to run things via docker-compose, so I just started having this same issue.

A question for those of you having the same problem: are you able to debug in Chrome DevTools? I start my app with node --inspect=5858 . and when it spits out the chrome-devtools://devtools... URL, I paste it into Chrome but all I get is a message that says "Debugging connection was closed. Reason: WebSocket disconnected." I'm curious if this is an issue with docker? Not sure though, just throwing that out there...

[tinganho]

I'm curious if this is an issue with docker

This is also my suspicion, though I thought I ruled it out with a tcpdump. And trying to run with node --inspect I don't get the same errors as you, are you sure you are pasting with the right URI? For me I map with a different port on the host than 5858.

Though one interesting thing is, although I don't get the same error. Nothing works in my debugger console.

I will file an issue on Docker as well.

[mulleady1]

Yep, definitely pasting the right URI. In fact I just repeated this scenario on a Ubuntu 16.04 machine and got the same result! Strange. I'll keep digging into it and update this thread or the docker one as appropriate.

[woraphol-j]

I am facing the same problem but I managed to attach the chrome devtool to the node running inside a container. Just run node with --inspect=0.0.0.0 rather than pure --inspect as it will only listen to a local connection. This way, I can get the chrome's devtool to work. For this reason, I doubt there is something wrong with Docker. This is supposed to be a bug in VS code itself.

[mulleady1]

Thank you! I had a feeling there was some flag I hadn't tried yet. Glad to hear we can still debug somewhere until this VSCode issue is resolved. Thanks again.

[mulleady1]

By the way, I can now get the VSCode debugger to attach when starting the node app with node --inspect=0.0.0.0:5858 👍 👍

[woraphol-j]

@mulleady1 Glad to hear you managed to get it to work so this can prove it might not be a VS Code bug. Would you mind sharing with me a couple of things as follows:

1. Your Node.js version in your docker container
2. Your configuration in launch.json file

I am still struggling to get this to work. I can get Devtool to attach quite fine but not for VS code.

[mulleady1]

Sure thing.

1. 7.7.1
2. Not sure if some of these settings are necessary, but my config currently looks like:

{
  "type": "node",
  "request": "attach",
  "name": "Attach",
  "port": 5858,
  "restart": true,
  "sourceMaps": false,
  "localRoot": "${workspaceRoot}/api",
  "remoteRoot": "/home",
  "protocol": "inspector"
}

[tiansivive]

@woraphol-j Same here!
Running node with --inspect=0.0.0.0:5858 allows me to connect the chrome debugger to it. However, source maps aren't supported which doesn't work for me since I'm using Typescript.

As for trying to attach VScode, still no luck. I'm using node 7.7.1 as well and my launch.json is the same as @mulleady1

[tinganho]

However, source maps aren't supported which doesn't work for me since I'm using Typescript.

VSCode (as well as Chrome Debugger) should support source map?

I'm just wondering if you can attach the Chrome Debugger to a remote container using --inspect=0.0.0.0:5858? (I can connect to it, but it never attaches).

[navossoc]

Can you do a quick test?
Try to change the type to node2 on your launch.json.

Let me know if that works.

[]'s

[tinganho]

@mulleady1 Do you mind share your Docker version as well?

[mulleady1]

Docker:

Mac:

Also, I have this setting checked in Chrome for a different reason, but maybe it's a piece to this puzzle:

[woraphol-j]

@navossoc Bingo!!
Changing from node to node2 magically works for me after struggling with this for many days. Finally get it to work, many thanks!
@tiansivive @tinganho please try @navossoc solution, it might work for you.

[navossoc]

@woraphol-j I have traced my issue to outDir in tsconfig.json.
If you change that value the source map resolution seems to be broken, even if you try to use absolute paths or any other kind of settings that changes the behavior of the source maps.

Seems there is a protocol change for node debugger and that transition is what is creating this whole problem.
See here: https://code.visualstudio.com/updates/v1_10#_node-debugging

You can also set the type to node and add the protocol to auto (it will choose inspector and works too). For now, seems to be the most "future ready" solution.

I'm using node v6.10.1. and my launch.json is something like this:

{
	"type": "node",
	"request": "launch",
	"name": "Launch Program",
	"program": "${workspaceRoot}\\lib\\index.js",
	"protocol": "auto"
},

[gerich-home]

Hi,

I observe the same issue when running my docker container (based on node:7.7.2-alpine) in docker-machine (VirtualBox) on Windows 7 and then trying to attach to it from vscode.
Neither of the following configurations work for me:

        {
            "name": "Attach1",
            "type": "node",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "inspector"
        },
        {
            "name": "Attach2",
            "type": "node",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "legacy"
        },
        {
            "name": "Attach3",
            "type": "node",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "auto"
        },
        {
            "name": "Attach4",
            "type": "node2",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "inspector"
        },
        {
            "name": "Attach5",
            "type": "node2",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "legacy"
        },
        {
            "name": "Attach6",
            "type": "node2",
            "request": "attach",
            "port": 9229,
            "restart": true,
            "sourceMaps": false,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": "/home/app/app/",
            "windows": {
                "address": "192.168.99.100"
            },
            "protocol": "auto"
        }

Here 192.168.99.100 is the ip adress that docker-machine env command yields me.

I run the application with the following docker-compose.yml:

  web:
    build: .
    command: node --inspect-brk=0.0.0.0:9229 index.js
    ports:
    - 80:80
    - 9229:9229

When I start the application I am able to see the following in the console:

Debugger listening on port 9229.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=0.0.0.0:9229/75b18c73-b7b1-4e41-83b2-91f28470cd86

When I open the url in the chrome (replacing 0.0.0.0 with 192.168.99.100) I am able to successfully start debugging the application (it stops on the 1st line of the application).
But when I am trying to attach from VsCode it just hungs forever showing like it is trying to attach.

After reading the above I did not clearly understand if somebody has the exact same behavior and if it has a workaround.

Additional note.
I observe the same when trying to run application as following:
node --debug-brk=0.0.0.0:9229 index.js

[gerich-home]

Seems to be related to the issue: #23257
Probably the wrong IP address is sent to vscode from container?

[weinand]

I just added a "VS Code Recipe" for how to debug transpiled source in Docker with VS Code. Please see https://github.com/weinand/vscode-recipes/tree/master/Docker-TypeScript

[tinganho]

@weinand I don't see any new configurations that you are using that might make my case work.

[weinand]

@tinganho does it help if you add a "protocol": "legacy" to your launch config?
What version of node are you running inside the container?
does it help if you pass --debug-brk=0.0.0.0:5858 to mocha?

[AndrewLaBabies]

I tested with following, debug not work. I am running in Mac with docker 17.03.1-ce, node v7.10.0 , VS code 1.12.2.

1. start nodejs
   --debug-brk=0.0.0.0:5858 or --debug=0.0.0.0:5858

2. launch.json

"name": "Attach",
"type": "node",
"request": "attach",
"protocol": "legacy",
"address": "localhost",
"port": "5858",
"restart": false,
"sourceMaps": true,
"outFiles": [
      "${workspaceRoot}/dist/**/*.js"
],
"localRoot": "${workspaceRoot}",
"remoteRoot": "/server",
"timeout": 10000

BTW, I also tried for setting of inspect, debugger didn't stop at the break point, but I can see the application calling DB with SQL in debug console.

[weinand]

@AndrewLaBabies does your program break correctly if you add a "debugger" statement?

[mulleady1]

Just FYI to whomever, remote debugging has been working like a charm for me lately. The biggest difference in my setup from when I was having trouble is that I switched to the edge channel for Docker for Mac. My configuration is:

Start node with node --inspect=0.0.0.0:5858 .

launch.json:

{
  "type": "node",
  "request": "attach",
  "name": "Attach",
  "port": 5858,
  "restart": true,
  "localRoot": "${workspaceRoot}/api",
  "remoteRoot": "/home",
  "protocol": "inspector"
}

Docker
Version 17.05.0-ce-mac11 (17656)
Channel: edge

Node
v7.9.0

Mac
El Capitan v10.11

[AndrewLaBabies]

@weinand , sorry for the late response.
Added "debugger" statement in ts file, the program breaks, vs code stopped in corresponding compiled js file at the line with "debugger" statement.
I am using the setting for inspector.

But the breakpoints set in vs code directly, which still don't work.

[weinand]

@AndrewLaBabies if your debugger statement does not result in a break in the TypeScript file but breaks in the generated JavaScript, I suspect that your source maps are missing or incorrect.

Make sure that the generated Javascript has a reference at the end that points to the source map and that the sourcemap has an entry in the "sources" array that points to the TypeScript file.

See my recipe for how that could look like.

[tinganho]

@weinand sorry for late response here as well.

@AndrewLaBabies if your debugger statement does not result in a break in the TypeScript file but breaks in the generated JavaScript, I suspect that your source maps are missing or incorrect.

As I downloaded a newer version of VSCode, it seems like I'm able to break(only using the inspector protocol), but only in JS file. I checked the sources property in the source map files and it seems they have the correct path.

One another thing is that the node process stalls (and I have to manually kill the process), when I try to detach the debugger(though, I'm not sure if it is VSCode fault here). It would be good if other people can confirm this as well.

It seems like my problem only occurs specific to my project. As I cannot create minimum verifiable bug case. (Though if you have async/await code it jumps to JS code, but it jumps back to TS code, in my minimum bug case).

I can do some more digging, when I got more time.

[weinand]

@tinganho you said: "if you have async/await code it jumps to JS code, but it jumps back to TS code".

This is normal since the generated sourcemap does not cover all the generated JavaScript. So there are "holes" in the JavaScript that doesn't map to TypeScript. You can avoid stepping through the JavaScript by setting the "smartStep" attribute to true.

[AndrewLaBabies]

@weinand , I double confirmed the sourceMaps were generated correctly, and sourceRoot pointing to the correct ts folder in docker container

[weinand]

@tinganho VS Code cannot access TypeScript source in the container and the node.js runtime doesn't care about the TypeScript.
So please make sure that the TypeScript source is available where VS Code is running (which is typically not the container). From VS Code's perspective there is no need to have the source available in the container.

The logic for finding the source in a remote Docker scenario is as follows:

• the node.js runtime in the Docker container hits a breakpoint and reports the JavaScript location as an absolute path in the container.
• VS Code converts the remote path to a local path via the remoteRoot/localRoot mapping from the launch config.
• if the JavaScript contains a source map reference, VS Code tries to locate the source locally by consulting the source map.

Please note: the above logic applies to the case where the source lives in separate files. If the source is inlined in the source map and the source map itself is inlined in the JavaScript, VS Code tries to use the inlined source.

[tinganho]

@weinand I think I got the debugging working now.

I didn't made any changes. Though I added and removed some debugging configurations. And at last I got it to work. I'm suspicious whether there could be any caching bug? Because my configurations looks exactly the same as before.

I think because my addition and deletion of configurations made my debugging configurations to take effect. Honestly, my debugging experience haven't been consistent, sometimes I cannot set breakpoints, sometimes I can. Sometimes other problems occur, sometimes not. It was very hard to pin point the exact problem.

[teyou]

In my recent experience is that the breakpoint only breaks correctly if I explicitly add a "debugger;" statement in my source code.

[Pistulls]

I ran in to these issues, used the 0.0.0.0 fix to get attach working again. Also needed to make sure the localRoot was correct in order for breakpoints to hit (in the launch.json). You'd also probably find when it only works with debugger statements it's not breaking in the actual code file.
Tested my fixes against the docker labs tutorial on mac and ubuntu: https://github.com/docker/labs/pull/313/files

[marknuzz]

If you're using jest, you may need to use the --no-cache option for jest. This fixed debugging for me in some cases.

[weinand]

Since this issue is quite old, and the discussions are difficult to follow, and VS Code is now at version 1.20.1, I will close this issue. If you still see issues in 1.20.1 please open new issues.