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 connor@xbox.com

[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

[azephiris]

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 connor@xbox.com

[azephiris]

@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. :(

[imajus]

I'm experiencing the same issue with VSCode + Chrome debugging. The app takes very long to load in Chrome with these debugger pauses. Closing the Chrome Developer Tools panel helps to drastically speed up the loading but we're using an auto refreshing feature on source code updates which makes it very hard to work with. Constantly toggling Chrome DevTools on and off is just disturbing.

I tried adding that perScriptSourcemaps option to my debugger configuration but it didn't seem to make any difference at all.

OS: Unbuntu 22.04

[hyltonw]

Hey, I'm still experiencing this same issue with VSCode & Chrome debugging as well. The webpage flashes rapidly whenever loading/reloading the page if you have breakpoints enabled in VSCode AND have the chrome DevTools opened. A workaround I could see if there was some hook we could attach to in our launch options to run a task. That way we could at least issue the command command:workbench.debug.viewlet.action.toggleBreakpointsActivatedAction as preLaunchTask and then also after the page loaded. But I'm not sure how realistic that is to implement.

But I mainly wanted to just bump this issue.

[YayC]

I've also run into this with a vite setup. A workaround is to only set breakpoints in the chrome console, and then debugging in vscode works as before with our webpack setup. It would be great if there was an config option to match on more of the file path along with the perScriptSourcemaps option

[SomervilleTom]

I originated https://github.com/microsoft/vscode/issues/211815 earlier today.

After the very helpful suggestion of @IllusionMH, I've searched the comments here for a workaround to my issue and haven't found any.

I'm happy to instrument my project if that's helpful, and upload a logfile.

I'll be using the Chrome developer tools in the meantime (I can't live with a 2+ minute startup time on every relaunch).

[SomervilleTom]

I've attached the gzipped log for your convenience:

vscode-debugadapter-f9626b01.json.gz

[SomervilleTom]

I offer the following data for motivation, context and clarity.

When I opened my now-closed issue yesterday, the CLOCK time (measured with a stopwatch) of my React dashboard app was 2:35 -- 2,100 seconds. The instrumented time for my workaround (bypassing the VSC debugger altogether) is 253 msec.

The VSC debugger adds FOUR ORDERS OF MAGNITUDE to the startup time.

The workaround I've been using since my last entry here yesterday is to run "yarn dev" from a command shell (outside VSC), open a regular Chrome browser on the development URL reported by VITE, and use the Chrome developer tool for breakpoints, value inspection, and console logs.

The convenience of having my debugger integrated with my IDE is worth something, perhaps even one order of magnitude.

I invite any guidance this community might offer regarding coding practices or bundling that might help workaround this issue. I've already refactored the JS code to do a single bulk import at startup and avoid individual import statements in the rest of the code base. That seems to have made no difference at all.

I follow a practice of providing one JS class per file -- export class Foo extends Bar {} is in a file named "Foo.js". I wonder if anything might be improved by refactoring the codebase to package multiple class definitions in a single file -- especially for "flyweight" classes that provide just behavior and do not change any state.

I really like VSC and I very much want to resume using the builtin debugger. I just can't afford a penalty of four orders of magnitude in startup time.

[SomervilleTom]

I've also run into this with a vite setup. A workaround is to only set breakpoints in the chrome console, and then debugging in vscode works as before with our webpack setup. It would be great if there was an config option to match on more of the file path along with the perScriptSourcemaps option

I've just tried this on my dashboard and it works well. So long as I set each breakpoint in Chrome developer tool (and NOT the VSC debugger), then startup time is fine and VSC navigates to the desired location with the desired information in the "Run And Debug" view.

NOTE: The Chrome developer tools must be opened for the in-browser breakpoints to take effect.

[alixmix]

I've just tried this on my dashboard and it works well. So long as I set each breakpoint in Chrome developer tool (and NOT the VSC debugger), then startup time is fine and VSC navigates to the desired location with the desired information in the "Run And Debug" view.

Having to set the breakpoints in is a bit roundabout and introduces extra friction. It's a good work around, but yeah it would be nice to have a solution that enables breakpoints to be set in VSCode directly one day.

[ruchira-codimite]

I was able to fix this by modifying my client config like this,

{ "name": "Client", "type": "chrome", "request": "launch", "url": "http://localhost:3000", "webRoot": "${workspaceFolder}/frontend", "runtimeArgs": [ "--disable-session-crashed-bubble", "--disable-infobars", "--allow-insecure-localhost" ], "sourceMaps": true, "sourceMapPathOverrides": { "webpack://_N_E/": "${webRoot}/" } },

[bensonz]

Has anyone tried to fix this? This thing is going crazy everytime I open up the devTools when debuggin with nextjs.

This is a recommended setup. Debuggin Nextjs

   {
      "name": "Next.js: debug full stack",
      "type": "node-terminal",
      "request": "launch",
      "command": "yarn run dev",
      "serverReadyAction": {
        "pattern": "- Local:.+(https?://.+)",
        "uriFormat": "%s",
        "action": "debugWithChrome"
      },
      "skipFiles": ["<node_internals>/**/*.js", "node_modules/**/*.js"]
    }

Becasue of this flip, the page loading is basically not responding. At first it was semi-acceptable becuase there are just a few, but then I added a chart element and this thing went crazy, keeps breaking into loadash's isObject method and stuff.

There is a workaround where you don't use this config, so effectively turning off the debug attached on frontend. Use the:

   {
      "name": "Next.js: debug server-side",
      "type": "node-terminal",
      "request": "launch",
      "command": "yarn run dev"
    },

And then manually set breakpoints in chrome's dev tool if you must. Or you can add debugger in your code, but then you wouldn't be able to disable it on the fly. So, pretty annoying, but not the end of the world.

I am just surprsied to see this issue go on for 4 years and no solution. Lol.

Also tbh I am not sure who is causing this issue, is it Chrome? Is it this extension? Or something else.