VSCode spawns hundreds of `rg` processes and then crashes with an out of memory (OOM)

[AaronFriel]

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

• VS Code Version: 1.90.2
• OS Version: Windows 11 10.0.22631

Steps to Reproduce:

1. Unclear - this began relatively recently (past couple days)
2. ???
3. VS Code executes hundreds of rg processes which consume all available memory until VS Code crashes with an OOM.

Screenshot showing "The Window terminated unexpectedly (reason: 'oom', code: '-536870904')":

Screenshot showing top showing the first of (many) pages of rg processes:

I took the first screenshot after clicking "Help -> About" to get my OS version information and the OOM occurred while I was copying the Windows 11 build information.

Related issues:

• 200979

• 174220

It looks like there is a defect in VS Code, which some users report occurring even with all extensions disabled, where it will repeatedly spawn rg processes until all memory is exhausted.

[chandra1109]

Thanks for creating the issue request Please try booting the GPU

[roblourens]

Likely an extension is trying to start lots of searches. You could check the full command line arguments on rg to see what it's searching for. VS Code also writes trace-level logs when a search starts.

[AaronFriel]

@roblourens where can I find the trace level logs to attribute this to an extension or feature?

[roblourens]

• F1 > "Set Log Level" > Trace
• Then I believe they would show up either in "Extension Host" or "Window" logs in the Output pane

[AaronFriel]

If VSCode OOMs and crashes, how can I view the logs?

[roblourens]

You can run the command "Open Logs Folder", which opens the folder on disk for the current vscode instance, but then you can navigate from that folder and hopefully find the folder for the window that crashed.

[AaronFriel]

The logs aren't super helpful. I do see this:

2813:2024-06-28 15:51:29.179 [trace] SearchService#search: 16606ms
2814:2024-06-28 15:51:29.179 [trace] SearchService#search: 16606ms
2815:2024-06-28 15:51:29.257 [trace] SearchService#search: 16685ms
2816:2024-06-28 15:51:29.257 [trace] SearchService#search: 16686ms
2817:2024-06-28 15:51:29.258 [trace] SearchService#search: 16686ms
2818:2024-06-28 15:51:29.259 [trace] SearchService#search: 16687ms
2819:2024-06-28 15:51:29.259 [trace] SearchService#search: 16688ms
2820:2024-06-28 15:51:29.260 [trace] SearchService#search: 16745ms
2821:2024-06-28 15:51:29.261 [trace] SearchService#search: 16746ms
2822:2024-06-28 15:51:29.261 [trace] SearchService#search: 16749ms
2823:2024-06-28 15:51:29.262 [trace] SearchService#search: 16750ms
2824:2024-06-28 15:51:29.263 [trace] SearchService#search: 16751ms
2825:2024-06-28 15:51:29.263 [trace] SearchService#search: 16754ms
2826:2024-06-28 15:51:29.264 [trace] SearchService#search: 16755ms
2827:2024-06-28 15:51:29.264 [trace] SearchService#search: 16756ms
2828:2024-06-28 15:51:29.265 [trace] SearchService#search: 16757ms
2829:2024-06-28 15:51:29.266 [trace] SearchService#search: 16760ms
2830:2024-06-28 15:51:29.335 [trace] SearchService#search: 16830ms
2831:2024-06-28 15:51:29.335 [trace] SearchService#search: 16833ms
2832:2024-06-28 15:51:29.335 [trace] SearchService#search: 16833ms
2833:2024-06-28 15:51:29.335 [trace] SearchService#search: 16836ms
2834:2024-06-28 15:51:29.336 [trace] SearchService#search: 16837ms
2835:2024-06-28 15:51:29.368 [trace] SearchService#search: 16871ms
2836:2024-06-28 15:51:29.368 [trace] SearchService#search: 16873ms
2837:2024-06-28 15:51:29.368 [trace] SearchService#search: 16873ms
2838:2024-06-28 15:51:29.368 [trace] SearchService#search: 16873ms
2839:2024-06-28 15:51:29.368 [trace] SearchService#search: 16874ms
2840:2024-06-28 15:51:29.400 [trace] SearchService#search: 16907ms

And you can see there are as many as five searches occurring (or concluding, most likely?) in a single millisecond.

I also see logs before that like this (formatted for readability):

2558:2024-06-28 15:51:16.142 [trace] SearchService#search {
  "_reason": "startFileSearch",
  "folderQueries": [
    {
      "folder": {
        "$mid": 1,
        "external": "vscode-remote://wsl%2Bubuntu-22.04/home/friel/c/github.com/[redacted]",
        "path": "/home/friel/c/github.com/[redacted]",
        "scheme": "vscode-remote",
        "authority": "wsl+ubuntu-22.04"
      },
      "excludePattern": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/CVS": true,
        "**/.DS_Store": true,
        "**/Thumbs.db": true,
        "**/.ruby-lsp": true,
        "**/*.old": true,
        "**/.classpath": true,
        "**/.factorypath": true,
        "**/.project": true,
        "**/.settings": true,
        "**/.ts-node": true,
        "**/.next": true,
        "**/.turbo": true,
        "**/bower_components": false,
        "**/node_modules": true
      },
      "fileEncoding": "utf8",
      "disregardIgnoreFiles": true,
      "disregardGlobalIgnoreFiles": true,
      "disregardParentIgnoreFiles": true,
      "ignoreSymlinks": false
    }
  ],
  "usingSearchPaths": false,
  "excludePattern": {
    "{**/.foam/**,**/.vscode/**/*,**/_layouts/**/*,**/_site/**/*,**/node_modules/**/*,**/.git,**/.svn,**/.hg,**/CVS,**/.DS_Store,**/Thumbs.db,**/.ruby-lsp,**/*.old,**/.classpath,**/.factorypath,**/.project,**/.settings,**/.ts-node,**/.next,**/.turbo,**/bower_components,**/node_modules}": true
  },
  "includePattern": {
    "**/*": true
  },
  "type": 1,
  "shouldGlobMatchFilePattern": true
}

Unfortunately these logs don't seem to indicate why these searches are spawned.

[AaronFriel]

I've taken to doing two things to mitigate this:

1. Increased WSL memory to 24GiB

2. Running this shell script in the background:

   while true; do 
   until [ $(pgrep '\brg\b' | wc -l) -ge 10 ]; do 
     sleep 1s; 
   done; 
   psgf '\brg\b'; # an to pgrep for pids and then `ps -F --forest -p $PID_LIST`
   killall rg; 
   done

The first is ineffective, the second seems to help, but I have no idea why VS Code is spawning so many rg processes still.

[andreamah]

Have you tried this with all extensions disabled when using WSL?

[AaronFriel]

Will try to run with extensions disabled for a few days. The issue is intermittent, I was able to use it without any issues yesterday, then today OOMed twice.

[AaronFriel]

@andreamah the extension bisect was non-deterministic! An interaction between the Foam (foam.foam-vscode) and Markdown All in One (yzhang.markdown-all-in-one) extensions appears to cause something like an infinite loop or at least a self-reinforcing loop that spawns rg processes until a timeout occurs.

It was very difficult to find a command to reproduce, and then to bisect it. Once I found a command - building a moderately complex project in a multi-folder workspace - that caused it, the bisect proceeded and I found that disabling one or the other mitigated the issue. A user in the first linked issue below noted the same.

Related issues:

• https://github.com/foambubble/foam/issues/1167
• https://github.com/yzhang-gh/vscode-markdown/issues/1225

[andreamah]

It could be that these extensions are using the findFiles extension API too often (which uses rg), and this has a compounding effect on your system.

[andreamah]

Please track these issues in their respective extensions.