question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Slow processing of variables on hitting a breakpoint

See original GitHub issue

Hello, I’m a maintainer of React Native Tools VS Code extension. The extension is used for debugging React Native applications. Under the hood the extension uses vscode-js-debug debugger to debug javascript apps.

Describe the bug After the update of VS Code to the version 1.57.0 we detected that processing of variables on the first hitting of a breakpoint can take quite a long time. However further breakpoints hittings are handled fine. We found out that such behavior appeared after the implementation of Support for renamed identifiers in sourcemaps feature in this PR. We looked through CDP logs and revealed that now js-debug retrieves the whole bundled code of the application (via “Debugger.getScriptSource” method) and processes it. We assume that this could take a long time.

https://user-images.githubusercontent.com/33267199/122180131-d17a5580-ce90-11eb-9d6f-f8a265b27e8b.mp4

To Reproduce The issue can be reproduced using a node attach scenario, but it requires some preparations.

Steps to reproduce the behavior:

  1. Prepare development environment for Android React Native following this guide
  2. Create a React Native app using the command:
    npx react-native init AwesomeProject
    
  3. We prepared a special version of RNT extension, in which we suppressed attachment to an application in debugging scenarios. You can download this VSIX and install it.
  4. Open your RN project in VS code and create Debug Android debugging configuration
    {
      "name": "Debug Android",
      "cwd": "${workspaceFolder}",
      "type": "reactnative",
      "request": "launch",
      "platform": "android"
    }
    
  5. Open App.js file and set a breakpoint on the 62 line (return statement)
  6. Run the Debug Android debugging scenario and wait until you see something like this in Debug console
    Starting debugger app worker.
    Attaching to the application
    Launching the application
    Established a connection with the Proxy (Packager) to the React Native application
    Debugger worker loaded runtime on port 9468
    
    The debugging scenario should launch the RN app on an Android emulator.
  7. Enable debugging in the launched application following this guide. If after that an error is shown in the app, click Reload button.
  8. Create the Attach debugging scenario
    {
      "type": "pwa-node",
      "request": "attach",
      "name": "Attach",
      "port": 9468,
      "sourceMaps": true,
      "continueOnAttach": true,
      "resolveSourceMapLocations": [
        "!**/debuggerWorker.js"
      ]
    }
    
    The port should be the same as a debugger worker has.
  9. Run the Attach scenario
  10. Continue on the first technical breakpoint (the debuggerWorker process is launched in --inspect-brk mode)
  11. After that, your previously set breakpoint should be reached

Probable solution We are not sure about the solution, but it might make sense to add a special parameter to debugging configurations to enable/disable the “Support for renamed identifiers in sourcemaps” feature. So, users can configure it if they really need additional processing of variables while debugging.

Log File Js-debug logs: vscode-debugadapter-f39647b7.json.gz CDP logs: currentCDPlogs.txt previousCDPlogs_vs_code_1_56.txt

VS Code Version: 1.57.0

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:3
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
connor4312commented, Jun 23, 2021

You can now set sourceMapRenames: false in the launch config to disable this functionality

1reaction
nthtrung09itcommented, Jun 23, 2021
Screen Shot 2021-06-24 at 12 52 57 AM

Experiencing the same issue. It takes about 2 minutes to be able to continue debugging. Version: 1.57.1 MacOS 11.5 Beta (20G5042c)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Java: slow performance or hangups when starting debugger ...
Debugger performance can be affected by the following: Method breakpoints will slow down debugger a lot because of the JVM design, they...
Read more >
Very slow "Evaluating local variables" dialog is making remote ...
During remote debugging, "Evaluating local variables" dialog pops up after ... e.g. while single-stepping or hitting a breakpoint or even switching a file)...
Read more >
Lldb is slow to resolve local vars - Swift Forums
Whenever I set breakpoint in Swift code in Xcode, LLDB takes at least 60 seconds to resolve types of local variables on hot...
Read more >
Debugging with GDB - Stopping and Continuing
Inside GDB, your program may stop for any of several reasons, such as a signal, a breakpoint, or reaching a new line after...
Read more >
Why do conditional breakpoints slow my program down so ...
When you hit a breakpoint, Windows stops the process and notifies the debugger. It has to switch contexts, evaluate the condition, decide that...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found