search

BurntSushi / ripgrep

ripgrep recursively searches directories for a regex pattern while respecting your gitignore
The Unlicense
48.97k stars 2.01k forks source link

Ripgrep misbehaves and has huge CPU usage runing on VSCodium from inside distrobox #2886

Closed MateusRodCosta closed 2 months ago

MateusRodCosta commented 2 months ago

Please tick this box to confirm you have reviewed the above.

What version of ripgrep are you using?

No idea, apparently it's from either VSCodium or a VSCodium extension

How did you install ripgrep?

Same as above, it's apparently internal to either VSCodium or from a VSCodium extension

What operating system are you using ripgrep on?

Host is Fedora Silverblue 40. ripgrep is apparently invoked by something from a VSCodium install inside a Fedora 40 distrobox.

Describe your bug.

Ever so often when using VSCodium I will notice a random high CPU usage while I am not compiling anything or otherwise doing something that makes sense to trigger it. By looking at any system resource monitor usage I will notice that it's usually cause by VSCodium, more precisely by a rg.

I usually solve this by killing it and the issue goes away for a while. It could be caused by any reason ranging from the atomic/immutable nature of the host file system or the container nature of the distrobox.

The command that is run is apparently as follow:

/usr/share/codium/resources/app/node_modules.asar.unpacked/@vscode/ripgrep/bin/rg --files --hidden --case-sensitive --no-require-git -g **/package.json -g !**/.git -g !**/.svn -g !**/.hg -g !**/CVS -g !**/.DS_Store -g !**/Thumbs.db -g !**/{node_modules,.vscode-test}/** --no-ignore --follow --no-config --no-ignore-global

What are the steps to reproduce the behavior?

Install VSCodium inside a distrobox, use normally

What is the actual behavior?

Huge unneeded CPU usage by ripgrep

What is the expected behavior?

No unneeded CPU usage

MateusRodCosta commented 2 months ago

Potentially related to https://github.com/microsoft/vscode/issues/225767, in case it's not a ripgrep issue but one in how VS Code uses it

BurntSushi commented 2 months ago

This isn't actionable on my end. Most of your issue is explaining an interaction point with a piece of software that uses ripgrep, and you haven't identified any specific issue with ripgrep itself. Ripgrep using CPU isn't a ripgrep problem. It's just doing what has been asked of it.

You need to provide an MRE for ripgrep specifically. I'm not going to install random IDEs to guess at and debug your workflow in the hope of reproducing the same thing as you. You need to provide not just a specific ripgrep command, but a corpus along with expected and actual results.

MateusRodCosta commented 2 months ago

This isn't actionable on my end. Most of your issue is explaining an interaction point with a piece of software that uses ripgrep, and you haven't identified any specific issue with ripgrep itself. Ripgrep using CPU isn't a ripgrep problem. It's just doing what has been asked of it.

Ah, my bad, yeah it's likely some weird interaction between VS Code (or one of its extensions) and ripgrep, no idea if distrobox even matters here.

You need to provide an MRE for ripgrep specifically. I'm not going to install random IDEs to guess at and debug your workflow in the hope of reproducing the same thing as you. You need to provide not just a specific ripgrep command, but a corpus along with expected and actual results.

I am not very sure how to debug this, as I don't know if it's a native VSCode feature that triggers it or a extension. I will see if I can reproduce and then I might re-open if it turns out to be ripgrep-specific. Or, in case it's not, report to the appropriate channels.

I did find this pointing that a specific VS Code extensions (in this case one related to PHP) was able to trigger it: https://community.devsense.com/d/877-high-cpu-usage-of-rg-process-when-symlinks-are-used There is also this closed issue: https://github.com/microsoft/vscode/issues/186279

In any case I will investigate further and I might come back when I get more info, sorry for the inconvenience and thanks for the patience.

MateusRodCosta commented 2 months ago

@BurntSushi I did figure out something that might be close to a "MRE", I maintain three flatpaks for Flathub (ChibiTracker, Digital and dtipbijays). Apparently sometimes when I build one of those flatpaks, rg might start taking ~80% and basically never stopping taking CPU (it even starts spinning the laptop fans). When that happens apparently just deleting the build-dir/ (where the files that will be in the final flatpak are saved) and .flatpak-builder/ (where any compilation step actually happens) folders will just make the rg process go away.

I would guess then that VSCode is telling ripgrep to keep accessing files in those folder and, in case there are too many files, it takes too long to complete and uses a lot of CPU for prolonged time.

BurntSushi commented 2 months ago

An MRE means you can provide precise instructions for another human to reproduce the issue you're seeing.