Node Remote Debug takes up to 1 min to attach when using Docker for Mac

[thaoula]

• VSCode Version: 1.32.0-insider (1.32.0-insider)
• OS Version: Osx Mojave 10.14.3
• Docker Version: 2.0.2.1
• Node 11.9

Steps to Reproduce:

1. Run a node application using --inspect in a docker container
2. Attempt to attach to remote application. It will take up to 1 minute to attach (i.e the orange bar appears in Vscode)

As soon as you run step 1, the Debugger Attached message appears in the container's console. Visual Studio Code still looks like it is trying to attach. After sometime up to 1 minute the debugger will attach and will hit the breakpoints like normal.

We have some developers who are working on the same project but using Windows. For them the debugger attach process is very fast.

I have attached a trace captured during the attached process from both Windows and Mac machines. This appears to be occurring on all our Mac machines.

Does this issue occur when all extensions are disabled?: Yes
Does the occur on Mac non-insider builds: Yes
Does this occur on Windows builds: No

debugadapter.mac.txt
debugadapter.windows.txt

[weinand]

@roblourens do you spot anything in the traces that would explain the slow attach?

[roblourens]

The mac one is definitely slower but there is not one thing that is slower, it just takes a very long time to receive scriptParsed notifications from the runtime and process their sourcemaps. The windows machine is doing the same amount of work in just a couple seconds.

Is the mac a fast machine with a decent amount of free memory and nothing hogging the CPU at the same time?

[thaoula]

My Mac is a core i9 MacBook Pro with 32 go of ram. There is 8gb of ram allocated to docker.

It appears to affect all our MacBooks all 2018 and above. We are working on the same project with the windows guys and they can attach very quickly.

We only have code, outlook, Skype and docker running on our Macs.

Like I mentioned previously. Debugger attached is display immediately after attach then waiting for the breakpoint to be hit.

[roblourens]

My guess would be that the network is slow between node in Docker and the debug adapter, but I don't know enough about Docker to troubleshoot it.

You could try attaching with chrome devtools to see whether it's equally slow? Navigate to http://127.0.0.1:6861 in a browser to see the available targets. I guess symptoms would be scripts and their sources showing up slowly in the "Sources" tab.

[thaoula]

Hi Rob,

I tried using the url above but got Websocket request was expected. However, I then used chome://inspect and the node dev tools.

The chrome dev tools opened instantly and displayed the sources. I could also hit a break point straight away however chrome did not show source maps so it was the raw Javascript and not the Typescript files.

I see the issue #69415 posted today is also reporting the same problem.

Regards,
Tarek

[roblourens]

I guess the other one was different. I'm not sure what's going on here

• Did you start the vscode debugger immediately after starting node or did it have a minute to start up?
• Are you sure all the sources were immediately available in chrome devtools or is it possible that your app scripts were immediately available but some of the node_modules were loading progressively for a while afterwards? For example if I pick a script at random that loaded late, file:///home/app/node_modules/compressible/index.js, you could find that and check how long it takes to show up in devtools.

Otherwise you could try taking another log to see if it picks up anything else?

Really the only thing I see is that getting Debugger.scriptParsed events from node happens relatively slowly, and there are 2000+ scripts getting loaded. And everything else like processing sourcemaps happens very quickly by comparison.

[thaoula]

We run docker-compose up and leave everything running all day. We periodically try to attach to node to debug code changes this used to be a very quick process. So to answer your first question we definitely already have node running when we attach.

In chrome dev tools the source are immediately available (without sourcemaps) and i can find the file using {Command} P and searching for compressible ... i can even browse the folders in the source tabs and see all the files.

I set trace to verbose and run again to see if it has more info
debugadapter.txt

This is the launch config we are using -

{
  "name": "Attach Id API",
  "type": "node",
  "request": "attach",
  "port": 6861,
  "address": "127.0.0.1",
  "restart": true,
  "sourceMaps": true,
  "smartStep": true,
  "localRoot": "${workspaceRoot}/dist",
  "remoteRoot": "/home/app/",
  "protocol": "inspector",
  "trace": "verbose",
  "skipFiles": [
    "<node_internals>/**"
  ]
}

Let me know if I can provide any more information.

[roblourens]

Thanks. That shows the same thing as far as I can tell. A couple random things to try, set with "sourceMaps": false, and try removing the localRoot and remoteRoot. You won't be able to set breakpoints but see if it finishes attaching any faster.

[thaoula]

Its the same. I tried the following -

{
  "name": "Attach Id API",
  "type": "node",
  "request": "attach",
  "port": 6861,
  "address": "127.0.0.1",
  "restart": false,
  "sourceMaps": false,
  "smartStep": false,
  "protocol": "inspector",
  "timeout": 0,
  "trace": "verbose"
}

debugadapter.txt

[thaoula]

I inlined the sourcemaps and the source using typescript so I can see the source code now in the Chrome DevTools.

I then tried debugging using the Chrome DevTools.

1. It seems to attach instantly and displays sourcemaps.
2. I can hit a break point in about 1-2 secs (open dev tools and fire a request using Postman)

In VSCode these changes mode no difference. Still takes a minute or so to attach.

[roblourens]

That's very weird. Is it possible for you to share the project/docker setup for me to try? Alternately I could give you steps to start the debug adapter in debug mode so you can capture a perf profile to see where it's spending its time, if you are willing to do that.

@weinand we could have a nice builtin way to capture profiles for node-based DAs like we do for the EH in vscode (although this is probably the first time I've wanted it!)

[thaoula]

Hi,

I am willing to start adapter in debug mode ... I will try and create a project for you also (but will have to be done after work) .. can we try both?

Regards,
Tarek

[thaoula]

Hi Rob,

I have created a minimal project and a debug trace from my computer. In a nutshell, the effect is not as bad with this project because it is small but there is still a noticeable delay.

To use please do the following:

1. Extract zip
2. NPM install
3. docker-compose up
4. Attach Api (in Debug)

Files
debug-test.zip
debugadapter.txt

Hope that helps :)

[roblourens]

Thanks! I am able to repro this. The debug adapter is indeed taking a long time to process each script event by doing some unnecessary work. I can take it from 20s to 3s pretty easily.

[roblourens]

Ok please try this in tomorrow's Insiders build. It should be much faster. It is still technically still doing a lot more than it needs to be but I can't refactor too much at this point in the month but it should be usable

[thaoula]

Thanks for your hard work!. We look forward to giving it a try tomorrow.

[thaoula]

Hi @roblourens,

I have been testing your fix today .. and this is what I have found.

1. The orange debug status bar now appears almost instantly 👍 .
2. Breakpoints cannot be hit until after about 30-40 seconds 👎 .

Does this comment "It is still technically still doing a lot more than it needs to be but I can't refactor too much at this point in the month but it should be usable" mean you will be working on this further? if so, is there an github ticket to watch?

Thanks for your help :)

Regards,
Tarek

[roblourens]

I have to look at this some more next week. I had to revert the change anyway.

[roblourens]

Alright, take 2, please try in Monday's Insiders build.

[thaoula]

@roblourens just wanted to say thanks for fixing this issue. It works great and attaches instantly.

[roblourens]

Awesome, thanks for confirming.