Skip to content

process.report.getReport is very slow when called in Extension Host, blocks most functionality #238607

Closed

Description

Does this issue occur when all extensions are disabled?: Yes/No

Version: 1.97.0-insider (user setup)
Commit: cc14c75
Date: 2025-01-23T10:37:55.126Z
Electron: 32.2.7
ElectronBuildId: 10660205
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.26100

Steps to Reproduce:

  1. Clone https://github.com/jakebailey/vscode-getreport-issue
  2. Run the extension
  3. Run the "Hello World" command
  4. Attempt to do anything with the editor

Image

I discovered this as part of dprint/dprint-vscode#99; for months my editor has been unresponsive at startup, unable to hover or even copy and paste now that there are paste providers, and this particular call is the culprit.

If I run Node directly, or call VS Code "as node", it does not exhibit these problems. My impression is that this has to do with VS Code patching all of the networking calls, since unfortunately getReport calls to the network (even though effectively all users use it to check if libc is musl or not).

Related: nodejs/node#55576

Activity

  1. deepak1556 commented on Jan 24, 2025

    @deepak1556
    Collaborator

    Thanks for the concise repro, I will try backporting the upstream fix and see if that helps.

  2. added
    bugIssue identified by VS Code Team member as probable bug
    upstreamIssue identified as 'upstream' component related (exists outside of VS Code)
    freeze-slow-crash-leakVS Code crashing, performance, freeze and memory leak issues
    nodejsNodeJS support issues
    upstream-issue-linkedThis is an upstream issue that has been reported upstream
    on Jan 24, 2025
  3. added
    confirmedIssue has been confirmed by VS Code Team member
    linuxIssues with VS Code on Linux
    windowsVS Code on Windows issues
    on Jan 24, 2025
  4. deepak1556 commented on Jan 24, 2025

    @deepak1556
    Collaborator

    If I run Node directly, or call VS Code "as node", it does not exhibit these problems. My impression is that this has to do with VS Code patching all of the networking calls, since unfortunately getReport calls to the network (even though effectively all users use it to check if libc is musl or not).

    If you have an open network socket, ex: a http request with keep alive then it should repro with vanilla node as well.

    Reading the relevant Node.js issue and the fix, it seems the extension still needs to call process.report.excludeNetwork = true to avoid the expensive dns resolution calls if they are not interested in the info.

    I would also need to backport nodejs/node#55602 so that excludeNetwork covers all cases.

    But I don't see how we can completely avoid this issue,

    1. Track and proactively reach out to extensions making report api calls with network info
    2. Flip the default of excludeNetwork in the extension host (this would be a breaking change)

    /cc Christof Marti (@chrmarti) Alexandru Dima (@alexdima)

  5. jakebailey commented on Jan 24, 2025

    @jakebailey
    MemberAuthor

    If you have an open network socket, ex: a http request with keep alive then it should repro with vanilla node as well.

    Interesting; this vaguely reminds me of nodejs/node#47228

    The hang requiring some other ongoing request sort of explains why this happens to me more consistently when Copilot is enabled...

  6. jakebailey commented on Jan 24, 2025

    @jakebailey
    MemberAuthor

    If this is a bug with keepAlive, it doesn't feel like excluding the network stuff would be the "right" fix, of course. But I also doubt it would actually hurt anything...

    (This issue doesn't affect me anymore since dprint changed was modified to not use this call when possible)

  7. removed this from the April 2025 milestone on Apr 17, 2025
  8. deepak1556 commented on Apr 17, 2025

    @deepak1556
    Collaborator

    Closing as there isn't much we can do here, nodejs/node#55602 is available in 1.99 so extensions can use to avoid the dns resolution calls.

  9. jakebailey commented on Apr 17, 2025

    @jakebailey
    MemberAuthor

    I mean, sort of, but that's a global option and it has to be set early enough. It sort of sucks that any extension can accidentally freeze the entire editor via this one function, and this one function is used heavily across libraries which have to load native code. The only way to avoid it is to ensure that the global variable is assigned early enough, or ensure that everyone avoids calling it, and so existing code today will still do the wrong thing.

  10. locked and limited conversation to collaborators on Jun 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugIssue identified by VS Code Team member as probable bugconfirmedIssue has been confirmed by VS Code Team memberextension-hostExtension host issuesfreeze-slow-crash-leakVS Code crashing, performance, freeze and memory leak issueslinuxIssues with VS Code on LinuxnodejsNodeJS support issuesupstreamIssue identified as 'upstream' component related (exists outside of VS Code)upstream-issue-linkedThis is an upstream issue that has been reported upstreamwindowsVS Code on Windows issues

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions