Endless CPU and memory occur in "node" when a symlink to / exists in the workspace

[sean-mcmanus]

• VS Code Version: 1.55.2 and the today's Insiders.
• OS Version: Ubuntu 20 (via WSL2).

Steps to Reproduce:

1. Go to some folder via the command line.
2. ln -s / ./test1
3. Open the folder in VS Code (i.e. the folder should have a symlink to the root named test1).

Bug: Node starts using 200% CPU and memory keeps increasing (slowly). Even adding test1 to files.exclude doesn't work. Using the Toggle Developer Tools->Performance logging shows no CPU usage.

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

[deepak1556]

Can you configure to exclude the folder under files.watcherExclude and see if the issue happens.

[sean-mcmanus]

That does not fix it.

[deepak1556]

Can you provide the output of cat /proc/<PID>/cmdline where PID is of the process with high cpu usage.

[sean-mcmanus]

/home/username/.vscode-server-insiders/bin/85f8ebf1687661c45fe2633bdd7f640164a20cc2/node/home/username/.vscode-server-insiders/bin/85f8ebf1687661c45fe2633bdd7f640164a20cc2/out/bootstrap-fork--type=watch

[deepak1556]

Thanks, what is the version of remote wsl extension being used ? Can you check if the issue goes away with "remote.WSL.fileWatcher.polling": false

[sean-mcmanus]

0.56.1 (latest version). remote.WSL.fileWatcher.polling is already set to false by default and explicitly setting it to false has no effect.

[deepak1556]

/cc @aeschli for remote-wsl scenario based on microsoft/vscode-remote-release#4637

[sean-mcmanus]

So it sounds like this is a Remote/WSL2-only issue? I could try the repro on a local Linux machine if you want.

[deepak1556]

I could try the repro on a local Linux machine if you want.

Yes that would be helpful if you can do it.

[sean-mcmanus]

Yeah, I don't repro it on my Linux arm64 machine when files.watcherExclude is set, but it repros when I set the path to false (which sounds like it's "by design", although it seems odd why files.watcherExclude doesn't inherit files.exclude like search.exclude does).

So it looks like the bug is that files.watcherExclude isn't working in the remote WSL scenario (unless there's some other factor I'm not aware of).

[bpasero]

@sean-mcmanus still repros in insiders?

[sean-mcmanus]

@bpasero This bug still repros with today's Insiders.

[bpasero]

@sean-mcmanus can you set log level to Trace:

And open the server output channel, open a file, make some changes, save and see what output you get from the file watcher. I am curious as to what file watcher is being used in your case.

Should be prefixed with something like [trace] [File Watcher ...

[sean-mcmanus]

@bpasero It says [remoteagent] [trace] [File Watcher (node.js)].

[bpasero]

@sean-mcmanus the node.js watcher is a specific one only being used for watching files that are not inside the workspace. There should be other messages including nsfw which is the watcher we use for deep recursive folder watching.

Anyway, I just tried this out myself both on WSL1 and WSL2 and already found 2 issues:

• the process explorer (from help) menu does not seem to reflect the high CPU usages (WSL: process explorer does not show CPU usage properly in remote #134475)
• I see a large spike in ripgrep running for a long time with many processes (WSL: ripgrep eagerly runs on startup consuming lots of CPU in this case #134476)

As for the file watcher process: I see it running and I see it consuming around 20% of CPU (that is what htop reports for me). It is somewhat expected that the watcher consumes CPU at least on startup on Linux but it will eventually settle down: Linux does not have efficient recursive file watching, so a watcher will have to recursively resolve all child folders of a certain root and install itself as watcher. I suspect this is causing the higher CPU load on startup from the watcher.

Anyhow, once we introduce a different file watcher, I suspect this might change because the new file watcher will no longer automatically follow symbolic links when encountered. Instead, you have to explicitly configure files.watcherInclude to add such symbolic links.

[sean-mcmanus]

@bpasero I see no nsfw logging messages. I'm using WSL2. I don't see a ripgrep process running. Yeah, I think the 200% in my repro description was supposed to be 20%, and it sounds like the new file watcher would fix it. It doesn't seem to "eventually settle down", but I assume that's because my root has too many files/folders.

[bpasero]

@sean-mcmanus but you don't have polling enabled right?

[sean-mcmanus]

Yes, no polling, "remote.WSL.fileWatcher.polling": false

[aeschli]

I tested with WSL1 with polling and WSL2 and observed the CPU:
WSL1 with polling shows peaks every time there is polling, but with my test cases, all managebale
WSL2 seems to have a bug with circular links: #135952

To verify we need to wait for @bpasero fix/workaround for #135952

[bpasero]

I am a bit confused by #121854 (comment) and I also think you referenced the wrong issue. Symbolic links are never automatically followed in the parcel watcher. But it is possible that the polling mode I implemented does actually follow symlinks and likely does not protect against circular symlinks.

[bpasero]

I verified that @parcel/watcher is not following symlinks even in polling mode where we use their snapshot feature. I tested a folder with circular symbolic links and was not able to find that watcher going into an endless loop. That doesn't mean though that maybe an extension with their own file watcher (such as TypeScript) wouldn't end up looping endlessly.

Refs: https://github.com/parcel-bundler/watcher/blob/7d88b1c8270befe2ce06b8ddbbfb37d26bb145ea/src/unix/legacy.cc#L42

[aeschli]

I didn't see any endless loops. I thought I saw a noticeable CPU uptick but measuring again today I cannot confirm that. So all is fine.