"Code Analysis in progress" forever (never starts?)

Python Language Server 0.2.87.0 (freshly deleted and reinstalled)
Python Extension version 2019.5.18678
VS Code 1.35.0
Linux RHEL 7

Code analysis never seems to properly finish? I have turned logging to Trace. The server starts, the Outline is created for whatever code is opened, but floating over any definition the float over text is just "Code Analysis in Progress" without end.

The only thing of note in the Python Ouput log just says Analysis of <whatever.whatever>(Library) Queued with no additional messages at any time no matter how long I wait. Go To Definition ability never loads.

The status bar, which used to show the (large but eventually decreasing to zero) number of files being analyzed, etc., now never says anything about analysis status. I feel like a few weeks ago it would show thousands/hundreds of files being analyzed, the number would gradually decrease, and then stop after a minute or two.

This no-definition-analysis behavior happens regardless of my "python.analysis.openFilesOnly" setting.

If I switch to Jedi, it quickly analyzes sufficiently to find definitions, so the issue goes away with Jedi. But, then I run into the Gitlens/Jedi outline symbols error, and have to turn off Gitlens. Any ideas?

After stopping/starting vscode multiple times, it finally analyzed the files.

Edit: all files are not analyzed :(

I'm getting the same behaviour -- no analysis happening:

Microsoft Python Language Server version 0.2.96.0
VS Code 1.35.0
Python Extension Version: 2019.5.18875
Ubuntu 19.04

Switching back to Jedi for now so I can keep working 😞

Same here, with a trace log I am seeing:

Starting Microsoft Python language server.
[Info  - 9:29:33 AM] Analysis cache path: /home/florian/.cache/Microsoft/Python Language Server
##########Linting Output - flake8##########
[Info  - 9:29:33 AM] GetCurrentSearchPaths /home/florian/sources/ara/.venv/bin/python 
[Info  - 9:29:33 AM] Python search paths:
[Info  - 9:29:33 AM]     /usr/lib/python3.7
[Info  - 9:29:33 AM]     /usr/lib/python3.7/lib-dynload
[Info  - 9:29:33 AM]     /home/florian/sources/ara/.venv/lib/python3.7/site-packages
[Info  - 9:29:33 AM]     /home/florian/sources/ara
[Info  - 9:29:33 AM] Configuration search paths:
[Info  - 9:29:35 AM] Microsoft Python Language Server version 0.2.96.0
[Info  - 9:29:35 AM] Initializing for /home/florian/sources/ara/.venv/bin/python
Opening document file:///home/florian/sources/ara/ara/api/serializers.py
Analysis of ara.api.serializers(Library) queued
Opening document file:///home/florian/sources/ara/ara/api/models.py
Analysis of ara.api.models(Library) queued
##########Linting Output - flake8##########
Opening document file:///home/florian/sources/ara/ara/api/auth.py
Analysis of ara.api.auth(Library) queued
##########Linting Output - flake8##########

Analysis is only queued.

Microsoft Python Language Server version 0.2.96.0
VS Code 1.35.1
Python Extension Version: 2019.5.18875
Debian unstable

I think it should be noted that hovering over a symbol only returns "Code analysis is in progress" (I googled this and the only result was the source code).

Seeing similar output. Could there be something with installed packages (another user in the issue referenced above mentioned seeing this in Conda – microsoft/vscode-docs#2741 (comment)):

this happens only when the selected interpreter is the one provided by conda

Here's what I've got installed in my environment (created through Poetry):

pip list

poetry run pip list
Package            Version 
------------------ --------
appdirs            1.4.3   
aspy.yaml          1.3.0   
astroid            2.2.5   
atomicwrites       1.3.0   
attrs              19.1.0  
black              19.3b0  
blinker            1.4     
certifi            2019.3.9
cfgv               2.0.0   
chardet            3.0.4   
Click              7.0     
entrypoints        0.3     
flake8             3.7.7   
Flask              1.0.3   
gunicorn           19.9.0  
identify           1.4.3   
idna               2.8     
importlib-metadata 0.17    
isort              4.3.20  
itsdangerous       1.1.0   
Jinja2             2.10.1  
json-logging       0.0.11  
jsonschema         3.0.1   
lazy-object-proxy  1.4.1   
maestro-python     0.1.5   
MarkupSafe         1.1.1   
mccabe             0.6.1   
more-itertools     7.0.0   
nodeenv            1.3.3   
pendulum           2.0.4   
pip                19.0.3  
pluggy             0.12.0  
pre-commit         1.16.1  
py                 1.8.0   
pycodestyle        2.5.0   
pyflakes           2.1.1   
pylint             2.3.1   
pyrsistent         0.15.2  
pytest             3.10.1  
pytest-mock        1.10.4  
python-dateutil    2.8.0   
pytzdata           2019.1  
PyYAML             5.1     
requests           2.22.0  
responses          0.10.6  
sentry-sdk         0.7.14  
setuptools         40.8.0  
six                1.12.0  
toml               0.10.0  
typed-ast          1.3.5   
urllib3            1.25.3  
virtualenv         16.6.0  
Werkzeug           0.15.4  
wrapt              1.11.1  
xmltodict          0.12.0  
zipp               0.5.1

I think it should be noted that hovering over a symbol only returns "Code analysis is in progress" (I googled this and the only result was the source code).

Yep -this was the behavior that prompted me to open the issue!

If there's a repo that reproduces this, that'd be great. A copy of a trace log which shows the analysis stopping could be useful, too. https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#filing-an-issue

Jake Bailey (@jakebailey)

Jake Bailey (@jakebailey) I sadly cannot provide the repo to reproduce, but the logs I posted in #1175 (comment) are all the logs I get with trace enabled :/ I do not think it ever starts at all.

Ah, my bad, I missed the trace lines in that output (distracted by the pylint text).

Not sure if it is of any help, but this is a backtrace of the language server:

#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x13a2fd4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x13a2f80, cond=0x13a2fa8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x13a2fa8, mutex=0x13a2f80) at pthread_cond_wait.c:655
#3  0x00007f32d5602c12 in CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#4  0x00007f32d56027f4 in CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) ()
   from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#5  0x00007f32d56071c4 in CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) ()
   from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#6  0x00007f32d5607541 in WaitForMultipleObjectsEx () from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#7  0x00007f32d5269d61 in Thread::DoAppropriateWaitWorker(int, void**, int, unsigned int, WaitMode) ()
   from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#8  0x00007f32d5264ba0 in Thread::DoAppropriateWait(int, void**, int, unsigned int, WaitMode, PendingSync*) ()
   from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so
#9  0x00007f32d52b6980 in WaitHandleNative::CorWaitOneNative(SafeHandle*, int, bool, bool) () from /home/florian/.vscode/extensions/ms-python.python-2019.5.18875/languageServer.0.2.96/libcoreclr.so

According to strace it never leaves this wait.

Unfortunately that doesn't help too much due to the CLR stuff (the LS is in C# so it runs within the CLR), other than knowing that there's some deadlock. Getting a real trace of where it's stopped would be something we'd do in VS, but that's of course not as simple to emulate on Linux (probably doable with vsdbg but I haven't used it).

One thing to try is the daily build to see if it's gone away in a few fixes since 0.2.96, by setting:

"python.analysis.downloadChannel": "daily"

Unfortunately that doesn't help too much due to the CLR stuff (the LS is in C# so it runs within the CLR), other than knowing that there's some deadlock. Getting a real trace of where it's stopped would be something we'd do in VS, but that's of course not as simple to emulate on Linux (probably doable with vsdbg but I haven't used it).

One thing to try is the daily build to see if it's gone away in a few fixes since 0.2.96, by setting:
"python.analysis.downloadChannel": "daily"

The daily download is not helping me, just tried it.

Happy to try vsdbg to get you a better trace, if someone can point me to some example

Jake Bailey (@jakebailey)

Jake Bailey (@jakebailey) Got you a reproducer: https://github.com/apollo13/vscode-bug -- Please follow the instructions in README.md. If anyone else could confirm that this sequence also generates a hanging analysis…

Note: For me analysis starts working once I do not run pip install -e . in the above example repo.

Thanks, I can reproduce it and have a fix. This is related to #1209, as well as #537 (comment).

I have 0.3.15. My workspace interpreter path no longer has the workspace path. However it wasn't moved to the user search path and the package in the root of my workspace is still not resolvable.

[Info - 4:56:51 PM] GetCurrentSearchPaths /Users/{user}/.pyenv/versions/3.7.2/bin/python
[Info - 4:56:51 PM] Interpreter search paths:
[Info - 4:56:51 PM] /private/var/folders/9q/mshp41rj5419tdv0ftt4bz380000gn/T/wbsqjziz.hqp
[Info - 4:56:51 PM] /Users/{user}/.pyenv/versions/3.7.2/lib/python3.7
[Info - 4:56:51 PM] /Users/{user}/.pyenv/versions/3.7.2/lib/python3.7/lib-dynload
[Info - 4:56:51 PM] /Users/{user}/.local/lib/python3.7/site-packages
[Info - 4:56:51 PM] /Users/{user}/.pyenv/versions/3.7.2/lib/python3.7/site-packages
[Info - 4:56:51 PM] User search paths:
[Info - 4:56:51 PM] /Users/{user}/Documents/Code/pymod_stress_test/lib
[Info - 4:56:51 PM] /Users/{user}/Documents/Code/pymod_stress_test/mod_tests
[Info - 4:56:52 PM] Microsoft Python Language Server version 0.3.15.0

Hmm, the fix wasn't supposed to move it down; the workspace root is always a search path even if it's not shown. Is the hang gone? Is it an import that goes unresolved, or something else? Do you have an example or updated repro? (Since I know you reported #537)

I am also on

Microsoft Python Language Server version 0.3.15.0

now and it works fine again. Thanks!

Ok, that's fair. The hang has been gone since I moved the ./lib and ./mod_tests to the extraPaths setting.

I found the issue. The package I wanted to resolve was mod_tests which is in my extraPaths. When I removed it from my extraPaths it became resolvable again. It seems that you have to decide whether to have a directory as an extraPath or a resolvable package. Sorry for the mix-up, in python both are allowable.

Interesting, I figured we'd allow both. Do you mean you had something like:

mod_tests
    + a
        + b
            + __init__.py

And added mod_tests to extraPaths to do import a.b, but also want import mod_tests.a.b to work?

That is exactly what I was looking for. I wanted to keep general utility functions in mod_tests and also have the ability to import sub_tests directly as sort of plugins.

Hmm, I still have an issue. My workspace is like this:

    folder1 
    folder2
    folder3

with all folder1 -> folder3 added to my python path with .pth files for each. I also added all of them to the extra paths settings. They all show up as part of "user search paths" in the python log.

I also added to my workspace another folder, let's call it "astrowonk_code" which has other python files I want to be able to import from jupyter (thus why it has .pth file pointing to it)

my_code->
    folder1
    folder2
    folder3
astrowonk_code/stuff.py

Nothing in astrowonk_code is getting analyzed. the path shows up in "interpreter paths" but the outlines aren't getting created nor are any float over definitions working.

But astrowonk_code does get partially analyzed if I put it also in extra_paths (though the python log still shows it only under "interpreter search paths.") except it still shows "Analysis in progress.." over every definition tool tip. eventually there is just nothing when floating over functions. (The outline sometimes gets made? seems inconsistent.)

So most of my code the analysis is working properly, but not all. Looks like I'm on 0.3.15.0 of the LS.

(also the endless analysis still happens if I don't add folder1-3 into extrapaths. If autocomplete.extrapaths is unset, Code Analysis in Progress lasts forever, even if all the paths I would add to extrapaths show up in "interpreter search paths"

if I add astrowonk_code to the extrapaths then it still only appears in interpreter paths, but folder1-3 now appear in both. ¯_(ツ)_/¯

We only consider code within the workspace to be user code. Everything specified in extraPaths is split into what is and isn't in the workspace, then placed accordingly. My impression was that my_code was your workspace, so astrowonk_code is outside of it.

If it's library code, then many features will not operate within the module, though the outline should always appear (symbol collection is separate).

As for the hang, it's a bit difficult for me to make any judgement without seeing the trace log output, specifically the path list. The issue I had fixed was that the whole workspace was being marked as "interpreter", so I'd need another example that I can run that would have the hang.

Jake Bailey (@jakebailey)

Jake Bailey (@jakebailey) I am on macOS, running

VS code Version 1.35.1 (1.35.1)
Microsoft Python Language Server version 0.2.96.0

I am using a virtual environment, with a Mac Ports interpreter. I keep experiencing the same problem, and a perpetual "Code Analysis in Progress..." What's the right information to report to be helpful?

I looked for .pth files (which I did not know of previously) and realized that some packages in my virtual environment use some:

/Users/jlumbroso/.local//share/virtualenvs/codePost-api-python-_uTOs40F/lib/python3.7/site-packages/pytest-cov.pth
/Users/jlumbroso/.local//share/virtualenvs/codePost-api-python-_uTOs40F/lib/python3.7/site-packages/easy-install.pth

Maybe this is expected, but I guess I am surprised that this affects the server entirely, even on examples that seem wholly unrelated, such as:

# VS code Version 1.35.1 (1.35.1)
# Microsoft Python Language Server version 0.2.96.0
class Person(object):
    def say(self, msg:str):
        print(msg)

def f() -> Person:
    return Person()

a = f()
b = Person()

# Neither a. nor b. provide "say" as an option.

I have tried to reproduce the conditions of this problem without success. Here is what I did: - I setup a blank environment with the same Pipfile (including the `mypack = {path = ".",editable = true}` line). - I created the venv with pipenv, and used it as target interpret. - I created a bogus `mypack` package with an empty `__init__.py` file. - I created the `example.py` file above. This time the code analysis worked.

I am not sure, besides the actual content of the code in mypack what is missing from the above protocol compared to my original context.

By the way, I followed the instructions here to reinstall the most recent version and got the same above reinstalled, making me wonder if I should use the beta version:

Starting Microsoft Python language server.
Downloading https://pvsc.azureedge.net/python-language-server-stable/Python-Language-Server-osx-x64.0.2.96.nupkg

The Pipfile I was considering today was:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
pytest = ">=4.4"
pytest-cov = ">=2.6"
coveralls = "*"
tox = "*"
PyYAML = "*"
pylint = "*"
pytest-subtests = "*"

[packages]
requests = "*"
PyYAML = "*"
urllib3 = "*"
currentPack = {path = ".",editable = true}

[requires]
python_version = "3.7"

Any help much appreciated!!

I am trying the beta channel, and it seems to address the current problem I was reporting.

I am still facing this issue on 3.8.5

Utkarsh Jain (@QuantumStatic)

Utkarsh Jain (@QuantumStatic) Same, actually, although I love VS Code, I ended up just switching to PyCharm for all Python-only projects, which seems (for now) to have a more reliable, consistent Python intelligent support in my experience: https://www.jetbrains.com/pycharm/

Jérémie "Sonnet 4.5" Lumbroso (@jlumbroso)

Jérémie "Sonnet 4.5" Lumbroso (@jlumbroso) There is much customisations available but, if they don't fix it I'll have to shift 😔. I did start a new issue hoping it to get some traction.

We are not as actively maintaining this project as we have previously; you're advised to try out Pylance, which we are actively developing: https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance #2096

Yes I downloaded Pylance I really liked it. There are some syntax highlighting issues but nonetheless, it's great.

Navigation Menu

Repository navigation

"Code Analysis in progress" forever (never starts?) #1175

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"Code Analysis in progress" forever (never starts?) #1175

Description

Activity

bcroq commented on Jun 7, 2019

SmileyChris commented on Jun 11, 2019

apollo13 commented on Jun 14, 2019

kbakk commented on Jun 17, 2019

kbakk commented on Jun 17, 2019

astrowonk commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

apollo13 commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

apollo13 commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

astrowonk commented on Jun 17, 2019

apollo13 commented on Jun 17, 2019

apollo13 commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

15 remaining items

jaredcm commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

apollo13 commented on Jun 17, 2019

jaredcm commented on Jun 17, 2019

jakebailey commented on Jun 17, 2019

jaredcm commented on Jun 17, 2019

astrowonk commented on Jun 18, 2019

jakebailey commented on Jun 18, 2019

jlumbroso commented on Jun 20, 2019

jlumbroso commented on Jun 20, 2019

QuantumStatic commented on Sep 5, 2020

jlumbroso commented on Sep 5, 2020

QuantumStatic commented on Sep 6, 2020

jakebailey commented on Sep 14, 2020

QuantumStatic commented on Sep 22, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions