New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enters infinite loop when home folder contains cyclic symlinks #1725
Comments
Huh, Pyright contains logic that specifically protects against cyclic symlinks. @jakebailey, any ideas here? |
@sin-ack, what version of pyright are you using? A bug was fixed in version 1.1.123 specifically to handle cyclical symlinks. The latest version is 1.1.128. |
I've tried to repro by manually creating cyclical symlinks in a local project, and the latest version of pyright handles it fine. My best theory is that you're running an old version of pyright. |
The only think I can think of here is that the I guess I'm more wondering why you'd want to open up your entire home folder as a workspace. I can't imagine that going well for exactly these sorts of reasons... |
@erictraut I am indeed running 1.1.128. @jakebailey I ran strace on Regarding the workspace comment... I did some digging. |
To be clear, do you see |
Here's a partial log of strace from the pyright process:
Seems like any symlink that links above triggers an infinite loop. |
I guess I'm trying to decide whether or not this is actually looping, or if it's just huge because it hits the filesystem root. I'd think the former case wouldn't occur; our traversal should be remembering the realpath of each folder and checking before it recurses. But, it really should not have continued when it saw |
If these fs accesses are performed by the loop that scans for source files, we should see the string "Skipping recursive symlink" appear in the log output. I've reviewed all of the other code paths in pyright where we resolve symlinks, and none of them should result in a recursive walk of the file system hierarchy. My only other thought is that it's a problem with the file watching code. |
Yeah, I went though too and didn't find anything. I don't think it'd be the file watching, since we don't actually watch anything in the workspace, and that's where I'm presuming the link begins. I'll have to spin up wine and see for myself. |
Is there anyway I can provide you with a debug log from my end? |
I'm unsure how to do this in emacs, but if you can set |
Here's a log at Trace level. Nothing happens after the last line, and pyright is stuck at 100% CPU. Trace log
|
That's the LSP trace, but the logs I'm in interested are our own log messages (those sent with Anyway, extracting out some bits:
It's not stalling during the source file search, so this would seem to be elsewhere. An exception occurs when installing the file watcher, so that's a bit concerning (we should probably print that), but in that case there wouldn't be a file watcher, so I'm at a loss as to which code comes next that can be getting stuck. |
I will try to profile the pyright process on my own end. Since it's (presumably) infinite looping in Node code, that might help me see which code paths are the hottest, which should reveal what's causing the loop. |
If you can manage that, that'd be most welcome. |
@sin-ack, any update on this issue? |
I am sorry, I'm currently very busy with work. I'll try to return to this after Monday. |
@sin-ack, any more clues on this one? |
I'm going to close this issue since we haven't heard anything in over two weeks. If you are still able to repro the problem and have additional clues, please post them here, and we'll re-open the issue. |
I do experience the same problem with Emacs + lsp-mode and latest pyright (freshly built from git b882b9c). |
Same here (Spacemacs with lsp-mode), pyright installed with |
Some logs would be very helpful to identify if this is still in the source file scanning part of the code. Unfortunately the above profile didn't really help, other than to say that a good amount of CPU time is spent asking the FS for the realpath of things (which is sort of expected, but maybe not to that degree). I think the kind of profile that would work best is the one that the Chrome DevTools captures, versus node's built-in trace (which just shows the top entries). |
In my case I nailed down the problem to |
@jakebailey, based on the profiles provided by @m-khvoinitsky, it's pretty clear that the time is being spent in the code that searches for source files (in the If my hypothesis is correct, this isn't really a bug in pyright, but there are things we could do to help protect against this situation — or at least make it more diagnosable.
Thoughts? |
I think both are a good idea, and I'd probably want to expand 1) to maybe print all symlinks in trace mode for better info. I'd want to wait to try and touch this until after today's release, though. Too little time for testing. 🙂 |
The latter case might be a bit incongruent with how VS Code treats symlinks, though; I'd want to test that out to see if VS Code presents symlinks as folders when they aren't within the workspace. |
It looks like
Makes sense because it is exactly what is written in the very first comment. |
Right, yeah. Has there been any insight into why your editor is trying to make your home directory a workspace? It'd be good to try and fix this, but I would also expect that opening a giant folder wouldn't be such a good idea either, and your previous comments implied it was an editor bug. |
Based on the evidence from this thread, this is not a bug. Pyright is handling cyclic symlinks correct. The same behavior would occur if you attempted to open the root of your drive or your home directory as a workspace. I'm therefore going to close the bug report. |
Describe the bug
My home folder contains Proton (from Steam) and Wine. Wine symlinks the
dosdevices/z:
folder back to/
, to provide Windows applications with access to my home filesystem. When Pyright is run and completion is requested, it scans my home folder, eventually reaching the.wine
folder, and then infinitely loops trying to readz:
(which is/
).To Reproduce
winecfg
at least once)Expected behavior
To not infinitely loop.
Editor & OS information
Editor: GNU Emacs 27.1
LSP Plugin:
lsp-mode
20210402.1701 +lsp-pyright
OS: Debian GNU/Linux bullseye/testing
The text was updated successfully, but these errors were encountered: