"Analyzing in background" message stuck with caching enabled (deadlock, no CPU usage)

Environment data

Language Server version: 0.4.24.0
OS and version: Windows 10 1903 (18362.356)
Python version (& distribution if applicable, e.g. Anaconda): Python 3.7.3

Expected behaviour

Python Language Server shouldn't get stuck analyzing files.

Actual behaviour

After a random amount of time using PLS (e.g. after anywhere from 0 minutes to several days), Visual Studio Code gets stuck "Analyzing in background...". The number of items is frequently small, but not always.

Logs

See attached. This is a log from several days, so that I could capture the issue
analyzing - stuck.txt

Additional

This repository is from https://github.com/xobs/haddecks

My local settings.json file looks like this:

{
    "python.autoComplete.extraPaths": [
        "deps/litedram",
        "deps/litescope",
        "deps/litex",
        "deps/litex_boards",
        "deps/lxsocdoc",
        "deps/migen",
        "deps/spibone",
        "deps/valentyusb"
    ],
    "python.jediEnabled": false,
    "python.analysis.logLevel": "Trace"
}

There is no .env file present.

It's possible that this is triggered by saving the file.

Relatedly: Sometimes PLS gives "Undefined" error messages for things like int and hasattr that are part of the core language.

#1573 may be related.

Does upgrading to the daily build (at least 0.4.34) fix the issue?

https://github.com/microsoft/python-language-server/wiki/Versioning-and-download-channels

I've been reliably encountering this on the daily build.

Actually on .4.37.0 from the daily build, when opening a Python buffer with nothing but import pandas, this happens 100% of the time.

Jake Bailey (@jakebailey)

Jake Bailey (@jakebailey) I'm now running:

`[Info - 1:21:38 AM] Microsoft Python Language Server versio

analyzing - 0.4.36.0 stuck.txt
n 0.4.36.0`

I have attached the log from it. Again, PLS is using up an entire core, and is stuck at "Analyzing in background, 3 items left..."

That's a really strange log. pickle is showing up on multiple levels of the dependency resolution, which doesn't seem correct... Maybe this will require #1414 to get a handle on if it's looping wrong or something.

It downloaded 0.4.40.0 today, which is also stuck.

Having the same issue with and without the daily build enabled.

This has been a recurring issue. I hope you guys can find a definitive solution soon.

Petros Schütz Schilling (@petrosschilling)

Petros Schütz Schilling (@petrosschilling) - what are your imports (major libraries) and could you please provide the log from the output window?

"python.analysis.logLevel": "Trace"

Sean Cross (@xobs)

Sean Cross (@xobs) - does it complete if you just open the workspace? I see from the log that files are being edited (its normal) so analysis restarts for the changed file and any modules that import it (i.e. something that depends on the changed file) which brings more stuff into view.

Mikhail Arkhipov (@MikhailArkhipov)

Mikhail Arkhipov (@MikhailArkhipov) Yes, it does usually complete if I just open the workspace. It's non-deterministic. Usually reloading the window fixes it on the first try, but I've seen instances where it takes two or three reloads to get it to successfully complete.

Sean Cross (@xobs)

Might be another manifestation of #1455 since I see a lot of 'analysis canceled'.
Sean Cross (@xobs) - yes, the analysis is heavily multithreaded so it appears to be a synchronization issue somewhere.

Findings at this point:

This has been an issue since the first persistence PR was merged.
If modules of type CompiledBuiltin are not persisted, then the code is able to make it past the hangup (discovered by observing which modules happened to be in a weird state at the hangup). But, not persisting them breaks the reload, so skipping them isn't an immediate fix.
Again, I can reproduce these on my Arch machine, but not my Windows machine. Have not yet tested on macOS.

I've figured it out! PR incoming. A combination of a number of bugs in various different parts of the code to do with caching.

The hang due to caching was fixed in my PR, but #1686 conflicted with caching in general, so we've disabled caching for the time being. Those on the beta channel should have their hanging fixed, either way. Stable users never had caching enabled so wouldn't have hit this hang.

See #1737 if you'd like a writeup on what the issue was (if you're into that sort of thing 🙂).

I'm still seeing this issue on both stable and beta channels. Does it make sense to open a new one or resurrect this one?

If your analysis is stuck and you definitely have caching disabled (the logs give the caching level), then that's a different hang and I'd appreciate a new issue.

I'm still on daily, and running 0.4.127.0. Should this be fixed? It's stuck right now at "Analyzing in background, 3 items left..." and it seems frozen. Doing a mouseover on items just says "Loading...", and there is one part that is underlined in red that says "unexpected token ''" which is not an actual error anymore (it popped up as I was typing the line).

Downloading https://pvsc.azureedge.net/python-language-server-daily/Python-Language-Server-win-x64.0.4.127.nupkg...
Language server download complete
Unpacking archive... done
[Info  - 8:37:59 am] Analysis cache path: C:\Users\smcro\AppData\Local\Microsoft\Python Language Server
[Info  - 8:37:59 am] Microsoft Python Language Server version 0.4.127.0
[Info  - 8:37:59 am] Workspace root: d:\Code\HaD\haddecks
[Info  - 8:38:00 am] GetCurrentSearchPaths D:\Software\ecp5-toolchain-windows-v1.6\bin\python.exe 
[Info  - 8:38:00 am] Interpreter search paths:
[Info  - 8:38:00 am]     d:\software\ecp5-toolchain-windows-v1.6\bin\lib
[Info  - 8:38:00 am]     d:\software\ecp5-toolchain-windows-v1.6\bin
[Info  - 8:38:00 am]     d:\software\ecp5-toolchain-windows-v1.6\bin\lib\site-packages
[Info  - 8:38:00 am] User search paths:
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\litedram
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\litescope
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\litex
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\litex_boards
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\lxsocdoc
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\migen
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\spibone
[Info  - 8:38:00 am]     d:\Code\HaD\haddecks\deps\valentyusb
[Info  - 8:38:02 am] Initializing for D:\Software\ecp5-toolchain-windows-v1.6\bin\python.exe
[Info  - 8:38:02 am] Analysis caching mode: None.

This issue was specifically when caching was enabled, and the fix was in caching. The issue is fixed, and caching is disabled anyway. Your issue sounds different and unrelated.

Alright, this issue is the same as the one I originally reported in #1601 (comment), so given that I'm running 0.4.127.0 does that mean that this issue should be reopened?

No, this case was specifically about caching. You can is different since it no longer about cache. Feel free to open a new issue. Thanks.

I see, I didn't realize that someone changed the bug name to indicate it was a caching problem. I don't have caching, so I'll re-post the bug with the original name.

Was this ever released? I still seem to be getting this issue. I am on windows but using the remote wsl plugin to edit code from within WSL. Is there anything I can provide to help?

Yes, this was released in November when this issue was closed. If you have another hang, it'd be best to create a new issue with your reproducer/the info the issue asks for.

Navigation Menu

Repository navigation

"Analyzing in background" message stuck with caching enabled (deadlock, no CPU usage) #1601

Environment data

Expected behaviour

Actual behaviour

Logs

Additional

48 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"Analyzing in background" message stuck with caching enabled (deadlock, no CPU usage) #1601

Description

Environment data

Expected behaviour

Actual behaviour

Logs

Additional

Activity

xobs commented on Oct 1, 2019

jakebailey commented on Oct 1, 2019

malmaud commented on Oct 1, 2019

malmaud commented on Oct 1, 2019

xobs commented on Oct 2, 2019

jakebailey commented on Oct 2, 2019

xobs commented on Oct 3, 2019

petrosschilling commented on Oct 3, 2019

MikhailArkhipov commented on Oct 3, 2019

MikhailArkhipov commented on Oct 3, 2019

xobs commented on Oct 3, 2019

MikhailArkhipov commented on Oct 3, 2019

48 remaining items

jakebailey commented on Oct 30, 2019

jakebailey commented on Nov 1, 2019

jakebailey commented on Nov 4, 2019

z4ce commented on Nov 8, 2019

jakebailey commented on Nov 8, 2019

xobs commented on Nov 20, 2019

jakebailey commented on Nov 20, 2019

xobs commented on Nov 20, 2019

MikhailArkhipov commented on Nov 20, 2019

xobs commented on Nov 20, 2019

autoferrit commented on Feb 7, 2020

jakebailey commented on Feb 7, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions