Vscode-js-debug: Debugger brakes rapidly on app load

[NathanBraslavski]

Describe the bug
I installed the latest version of vscode today (with the new debugger) and since then every time I run the app the debugger brakes and continues rapidly until the app loads (see attached gif).

(lunching the app from chrome directly will not cause that issue)

About the setup:
I am running Angular 8.2.3
with chrome dev tools open:

"name": "Chrome qdev",
"type": "chrome",
"request": "launch",
"port": 9876,
"url": "http://localhost.<URL>:4200",
"runtimeArgs": [
                "--auto-open-devtools-for-tabs"
],
"sourceMaps": true,
"smartStep": true,
"skipFiles": [
                "node_modules/*"
],
...

I also tried to see if adding remote-debugging-port=9876 makes any difference, and it didn't.

Log File
I noticed there are a lot of calls to Debugger.resumed in the log, but I am not sure what's causing it and how to continue from here.
vscode-debugadapter-1.json.gz

VS Code Version: 1.47

Additional context
OS: windows 10
I am using HMR but I also tried without it, go similar results.

Thanks!

[connor4312]

This is working as designed; we ask Chrome to pause before executing scripts with sourcemaps so that we can make sure to set breakpoints in time. As of https://github.com/microsoft/vscode-js-debug/pull/562 we'll skip doing that if there's no breakpoints set. I'm not yet sure if there's a way we can signal devtools to not flip out like that.

[thaoula]

Hi @connor4312, we are experiencing something similar to this on node startup and attachment. The debug stops on random lines of internal node code that have no breakpoints. This only started happening in recent builds.

[connor4312]

This should not happen in Node (+ Node doesn't support the sourcemap breakpoint used in browsers). Can you capture a trace log using these instructions?

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to [email protected]

[thaoula]

Hi @connor4312,

Thanks for the speedy response.

I have provided a screenshot of the random stops .. this happens several times before hitting the breakpoint.

This is our config for the attach

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

vscode-debugadapter-0.json.gz

[KrakenZ]

Because of this and probably some other changes, our application now takes TWO minutes to load with the vscode debugger on each refresh. The debugger was never any good but this is absolutely terrible for me. I'll just use the built-in chrome/firefox debugger for now.

[connor4312]

@KrakenZ apps shouldn't take that long! Please collect a trace log using these instructions:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to [email protected]

[KrakenZ]

@connor4312 there it is: [redacted]
The last Debugger.resume({}) happens at +2:54.955. Crazy, isn't it?

[connor4312]

@KrakenZ thanks for the log! You're running into https://github.com/microsoft/vscode-js-debug/issues/598 which is fixed in the latest nightly build.

[NathanBraslavski]

@KrakenZ thanks for the log! You're running into #598 which is fixed in the latest nightly build.

@connor4312 thanks! looks like installing the nightly build of "vscode-js-debug" solved my issue as well

[connor4312]

Good to hear! I'll keep this issue open to attempt to address the cosmetic flickering issue. It will still happen even with that fix (just a couple times, though, instead of hundreds).

[connor4312]

We will need a fix in Chrome for this. Tracking this here: https://bugs.chromium.org/p/chromium/issues/detail?id=1131204

[fortinmike]

I'm hitting the same issue as @KrakenZ where our app starts very slowly (> 30s) on initial startup and reload while the debugger flashes repeatedly, when there is a breakpoint set. It's been doing this for a while. We're not using Angular though, so maybe it's some other edge case than #598? @connor4312 I've collected the logs and sent them to you by email.

For the record, here's what it looks like. It's bad enough to prevent us from using the VS Code debugger entirely.

https://user-images.githubusercontent.com/118257/102904498-d0b3ba00-443f-11eb-8a39-caaa2b07f534.mp4

[connor4312]

You may be able to add "perScriptSourcemaps": "yes" to your launch.json to use an improved behavior that might work better, looks like the automatic detection did not trigger on your application.

I'm curious what your build setup looks like?

[fortinmike]

When I add "perScriptSourcemaps": "yes" to my launch config VS Code says the property is not allowed. Pretty sure I put it in the correct spot (at the root of the launch config, right beside sourceMapPathOverrides). In any case, it didn't seem to change anything (I'm on VS Code 1.52.1 and msjsdiag.debugger-for-chrome v4.12.11).

{
  "name": "Chrome - Launch and Debug",
  "type": "chrome",
  "request": "launch",
  "url": "https://localhost:3010",
  "sourceMaps": true,
  "webRoot": "${workspaceRoot}/dist",
  "perScriptSourcemaps": "yes",
  "sourceMapPathOverrides": {
    "webpack:///./*": "${webRoot}/*",
    "webpack:///src/*": "${webRoot}/*",
    "webpack:///*": "*",
    "webpack:///./~/*": "${webRoot}/node_modules/*",
    "webpack://lib/../*": "${workspaceRoot}/../ripple/lib/*"
  },
  "runtimeArgs": [
    "--disable-session-crashed-bubble",
    "--disable-infobars",
    "--allow-insecure-localhost"
  ]
}

Can you see what triggers the debugger pause so often from the logs?

We use a mostly standard webpack build setup, although the on-disk layout might be a bit unorthodox. It's split into two root folders:

• app (contains custom source and assets but no build logic and no webpack)
  
  
  
  • launch.json
  
  
• ripple (an in-house library, you should see references to that in the logs I sent you)
  
  
  
  • source files
  
  
  • package.json scripts
  
  
  • build script (prepares some stuff before actually invoking webpack)
  
  
  • webpack.config.js
  
  

We trigger a build by invoking, from the app's root, a script that's defined in our library's package.json, which builds the app and the library as one using the webpack config that's located in the library itself. This allows our app's repo to contain only custom stuff and allows us to track the webpack config and build scripts in the library's repo for reuse in other apps. We make tons of apps using our library and that setup works well for us.

I don't know if that on-disk layout might somehow prevent the automatic detection in vscode-js-debug from working? I can share the project privately if need be, to help diagnose this.

P.S.: The sourceMapPathOverrides might need to be cleaned up, but we needed to add those at one point to make breakpoints work within our library, with our setup mentioned above.

[connor4312]

Thanks for the logs. It looks like it's actually working correctly, but in your code is still hitting a lot -- normally we request the runtime to pause before any script with a sourcemap, but with perScriptSourcemaps we instead only ask the runtime to pause when a script includes the filename of a file where a breakpoint was set. In your case, the file is index.js and there's ~400 other files in your build also named index.js.

I will have to think of the best way to deal with this. In the meantime you can also get around this issue by using a non-module devtool mode such as inline-source-map, so that a single script and sourcemap is created for each chunk rather than for each individual module in the build.

[fortinmike]

Oh, makes sense! We use the component folder pattern so we in fact have one index.js per (react) component, hence the high number of files with the same name.

I'll take a look at the inline-source-map dev tool but we had various issues with different webpack dev tools before settling on our current non-production choice (eval-cheap-module-source-map) so I'm still interested in seeing this resolved. I you need any other info let me know!

[kzeitz]

I believe I am having running into that same issue as @KrakenZ and @fortinmike as well.

The repo is fairly large, and the slow down at startup is in the 4-5 minute range which makes using the vscode-js-debug practically unusable.

If no breakpoints set or enabled, things start up in a reasonable amount of time, and the chrome debugger doesn't do the 'flash repeatedly' thing. If I wait till after the webpack [HMR] Waiting for update signal from WDS... I can then set or enable breakpoints without apparent 'penalty' and things seem to work after that as I'd expect.

Using pwa-edge behaves exactly the same way, lending support that it is an interaction with chrome. Also as stated by @thaoula this isn't a problem when launching directly from chrome. All my peers using intelli-j enjoy pointing out that intelli-j doesn't have the issue either.

Like @fortinmike we are using devtool: 'eval-cheap-module-source-map'

Here is my launch config.

"version": "0.2.0",
    "configurations": [
        {
            "name": "Launch xxx in Chrome",
            "request": "launch",
            "type": "pwa-chrome",
            "url": "http://localhost:5000",
            "webRoot": "${workspaceFolder}/apps/xxx/src",
            "outFiles": ["${workspaceFolder}/apps/xxx/src/**/js/*.js"],
            "trace": true
    }

Here's the log...
vscode-debugadapter-c27017bf.json.gz

I'd really like to get this resolved so I can debug in vs-code otherwise I need to find a different option.

Please let me know if there is further information that can provide that will help.

Update: I checked the latest nightly build. It behaves the same way. :(