vscode-jupyter: Python debugger dataviewer is broken if multiprocessing is used at some point earlier in the script
Applies To
- Notebooks (.ipynb files)
- Interactive Window and/or Cell Scripts (.py files with #%% markers)
What happened?
When debugging a python file (OS : Windows, Environnement : Anaconda), right clicking on a numpy array or a pandas dataframe in the “variables” side panel offers the option to “view the value in the data viewer” (it might not be the exact words, my vscode install is configured in another language).
When I click on it, an error appears : “Cannot read properties of undefined (reading ‘disposed’)”. And nothing else happens.
I tried with both the prerelease and commercial versions of Jupyter, to no avail.
In the Jupyter logs, “xxxx” is my Windows session username
Here is my lanch.json code for the debugging configuration I’m using :
{ "version": "0.2.0", "configurations": [ { "name": "Python : fichier actif", "type": "python", "request": "launch", "program": "${file}", "console": "integratedTerminal", "justMyCode": false } ] }
VS Code Version
Version : 1.75.1 (user setup) Validation : 441438abd1ac652551dbe4d408dfcec8a499b8bf Date : 2023-02-08T21:32:34.589Z Electron : 19.1.9 Chromium : 102.0.5005.194 Node.js : 16.14.2 V8 : 10.2.154.23-electron.0 Système d’exploitation : Windows_NT x64 10.0.19044 Sandboxé : No
Jupyter Extension Version
v2023.1.2010391206 AND v2023.2.1000461014
Jupyter logs
info 17:57:03.945: Found debugAdapterPython on Debug Configuration to use
info 17:57:04.764: Process Execution: > c:\Anaconda3\python.exe -c "import pandas;print(pandas.__version__)"
> c:\Anaconda3\python.exe -c "import pandas;print(pandas.__version__)"
error 17:57:05.365: [TypeError: Cannot read properties of undefined (reading 'disposed')
at Zh (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:17:165040)
at ef.getDataFrameInfo (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:17:165522)
at async Fk.ensureInitialized (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:519924)
at async Fk.getDataFrameInfo (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:518749)
at async Ek.onVariablePanelShowDataViewerRequest (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:510752)
at async s.h (d:\xxxx\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:96:108008)]
warn 17:57:05.366: DataScience Error [TypeError: Cannot read properties of undefined (reading 'disposed')
at Zh (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:17:165040)
at ef.getDataFrameInfo (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:17:165522)
at async Fk.ensureInitialized (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:519924)
at async Fk.getDataFrameInfo (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:518749)
at async Ek.onVariablePanelShowDataViewerRequest (d:\xxxx\.vscode\extensions\ms-toolsai.jupyter-2023.2.1000461014\out\extension.node.js:24:510752)
at async s.h (d:\xxxx\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:96:108008)]
Coding Language and Runtime Version
Python 3.9.7
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
conda 4.10.3
Running Jupyter locally or remotely?
None
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 4
- Comments: 16 (7 by maintainers)
Commits related to this issue
- Fix interface implementation and handle undefined kernel in KernelVariables Fix #12845 — committed to microsoft/vscode-jupyter by roblourens a year ago
- Fix interface implementation and handle undefined kernel in KernelVariables (#12865) Fix #12845 — committed to microsoft/vscode-jupyter by roblourens a year ago
I have exactly the same problem as @sacha-hirsch Did you find another way to display your dataframe like in the Dataframe Viewer. (I have over 1 million rows in my case)
Do we have an update to fix this bug?
Here you go with a minimal example
Commenting line 14 will make the bug disappear
jupyter_bug_minimal_example.txt
I have some news ! First, the bad one : with the newest release, the error message doesn’t come up anymore… but nothing else happens. So this is still not resolved.
However, I noticed that this bug only happens when I have multiprocessing code running at some point earlier in the program (multiprocessing.Pool().map is called and resolved before the breakpoint where I’m peeking at the array) !
You can find attached two logs of the same program with the same breakpoint, one with multiprocessing enabled (multiprocessing.Pool().map is called and resolved earlier in the program; the bug appears) and one with multiprocessing disabled (multiprocessing.Pool().map is not called earlier in the program; no bug, data viewer works perfectly).
The bug also disappears if the breakpoint is placed before the call of multiprocessing.Pool().map
So, I guess a better title for this issue would be “dataviewer broken when multiprocessing is used earlier in the script”
I should have checked with something closer to a minimal example before posting, sorry!
Thank you all for your help!
vscode_variable_peeking_bug_multiproc_enabled.txt vscode_variable_peeking_no_bug_multiproc_disabled.txt
Hello @DonJayamanne , This is probably because my minimal code is not meant to be run in jupyter but as a classic python .py file.
This issue was probably categorized as “vscode-jupyter” because it deals with the dataviewer but it is first and foremost a python debugger issue, not a jupyter issue.
FYI I just restested the minimal code with python 3.11 and the last version of VScode, and the bug is still there. Calling the multiprocessing module somewhere in the code will break the debugger dataviewer for all the following code lines , even if meanwhile the multiprocessing call has been resolved.
Glad to see this issue is still being investigated.
Best of luck !