spyder
spyder copied to clipboard
spyder-ide
IPython kernel hangs when using other graphics backend than "inline"
Issue Report Checklist
- [x] Searched the issues page for similar reports
- [x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
- [x] Reproduced the issue after updating with
conda update spyder(orpip, if not using Anaconda) - [ ] Could not reproduce inside
jupyter qtconsole(if console-related) - [x] Tried basic troubleshooting (if a bug/error)
- [x] Restarted Spyder
- [x] Reset preferences with
spyder --reset - [x] Reinstalled the latest version of Anaconda
- [x] Tried the other applicable steps from the Troubleshooting Guide
- [x] Completed the Problem Description, Steps to Reproduce and Version sections below
Problem Description
Potentially the same issue as: https://github.com/spyder-ide/spyder/issues/16400
When using any other graphics backend than "Inline", (i.e. Automatic, Qt5 or Tkinter), the kernel hangs when running a script. Infrequently, it works as expected, but there doesn't seem to be a pattern to this. The kernel must be restarted to regain functionality. Interrupt does not work.
What steps reproduce the problem?
- Set graphics backend to Automatic, Qt5 or Tkinter
- Run a script that produces a plot
What is the expected output? What do you see instead?
Expected: A new plot window and any console output from the script Actual: No plot window, no console output
Versions
- Spyder version: 5.4.3
- Python version: 3.9.17
- Qt version: 5.15.2
- PyQt version: 5.15.7
- Operating System name/version: Windows 10 22H2
Dependencies
# Mandatory:
atomicwrites >=1.2.0 : 1.4.0 (OK)
chardet >=2.0.0 : 4.0.0 (OK)
cloudpickle >=0.5.0 : 2.2.1 (OK)
cookiecutter >=1.6.0 : 1.7.3 (OK)
diff_match_patch >=20181111 : 20200713 (OK)
intervaltree >=3.0.2 : 3.1.0 (OK)
IPython >=7.31.1,<9.0.0,!=8.8.0,!=8.9.0,!=8.10.0 : 8.12.2 (OK)
jedi >=0.17.2,<0.19.0 : 0.18.1 (OK)
jellyfish >=0.7 : 0.9.0 (OK)
jsonschema >=3.2.0 : 4.17.3 (OK)
keyring >=17.0.0 : 23.13.1 (OK)
nbconvert >=4.0 : 6.5.4 (OK)
numpydoc >=0.6.0 : 1.5.0 (OK)
paramiko >=2.4.0 : 2.8.1 (OK)
parso >=0.7.0,<0.9.0 : 0.8.3 (OK)
pexpect >=4.4.0 : 4.8.0 (OK)
pickleshare >=0.4 : 0.7.5 (OK)
psutil >=5.3 : 5.9.0 (OK)
pygments >=2.0 : 2.15.1 (OK)
pylint >=2.5.0,<3.0 : 2.16.2 (OK)
pylint_venv >=2.1.1 : 2.3.0 (OK)
pyls_spyder >=0.4.0 : 0.4.0 (OK)
pylsp >=1.7.2,<1.8.0 : 1.7.2 (OK)
pylsp_black >=1.2.0 : 1.2.1 (OK)
qdarkstyle >=3.0.2,<3.2.0 : 3.0.2 (OK)
qstylizer >=0.2.2 : 0.2.2 (OK)
qtawesome >=1.2.1 : 1.2.2 (OK)
qtconsole >=5.4.2,<5.5.0 : 5.4.2 (OK)
qtpy >=2.1.0 : 2.2.0 (OK)
rtree >=0.9.7 : 1.0.1 (OK)
setuptools >=49.6.0 : 68.0.0 (OK)
sphinx >=0.6.6 : 5.0.2 (OK)
spyder_kernels >=2.4.3,<2.5.0 : 2.4.4 (OK)
textdistance >=4.2.0 : 4.2.1 (OK)
three_merge >=0.1.1 : 0.1.1 (OK)
watchdog >=0.10.3 : 2.1.6 (OK)
zmq >=22.1.0 : 23.2.0 (OK)
# Optional:
cython >=0.21 : None (NOK)
matplotlib >=3.0.0 : 3.7.1 (OK)
numpy >=1.7 : 1.24.3 (OK)
pandas >=1.1.1 : 2.0.3 (OK)
scipy >=0.17.0 : 1.11.1 (OK)
sympy >=0.7.3 : 1.11.1 (OK)
Hey @James-F1dev, thanks for reporting. I can't reproduce this problem on Linux.
@dalthviz, could you check this on Windows?
I, along with many of my students in a computational physics class, using macs, are also having this issue. Since this ticket and 16400 seem to have issues reproducing what is happening for us, I made a little video showing what I mean. It's here:
https://youtu.be/2HIiaCM5mr8
I did YouTube because I narrate over it. As for versions of other possible dependencies, all my students would have installed Anaconda 1-2 weeks ago, so everything else would have been fairly up to date. I haven't updated anything on my conda package besides Spyder and see the same thing. Hope that's helpful.
@dalthviz, could you check this on Windows?
I was unable to reproduce this using the Windows installer (Spyder 5.4.5) or an Anaconda installation using an env created with something like:
conda create -n spyder-graphics -c conda-forge python=3.9 spyder pandas numpy matplotlib
- Code used while testing:
import matplotlib.pyplot as plt
import numpy as np
from matplotlib import colors
from matplotlib.ticker import PercentFormatter
# Creating dataset
np.random.seed(23685752)
N_points = 10000
n_bins = 20
# Creating distribution
x = np.random.randn(N_points)
y = .8 ** x + np.random.randn(10000) + 25
# Creating histogram
fig, axs = plt.subplots(1, 1, figsize=(10, 7), tight_layout=True)
axs.hist(x, bins = n_bins)
# Show plot
plt.show()
- Env details:
# packages in environment at C:\Users\dalth\anaconda3\envs\spyder-graphics:
#
# Name Version Build Channel
alabaster 0.7.13 pyhd8ed1ab_0 conda-forge
arrow 1.2.3 pyhd8ed1ab_0 conda-forge
astroid 2.15.6 py39hcbf5309_0 conda-forge
asttokens 2.2.1 pyhd8ed1ab_0 conda-forge
atomicwrites 1.4.1 pyhd8ed1ab_0 conda-forge
attrs 23.1.0 pyh71513ae_1 conda-forge
autopep8 2.0.4 pyhd8ed1ab_0 conda-forge
babel 2.12.1 pyhd8ed1ab_1 conda-forge
backcall 0.2.0 pyh9f0ad1d_0 conda-forge
backports 1.0 pyhd8ed1ab_3 conda-forge
backports.functools_lru_cache 1.6.5 pyhd8ed1ab_0 conda-forge
bcrypt 4.0.1 py39hf21820d_0 conda-forge
beautifulsoup4 4.12.2 pyha770c72_0 conda-forge
binaryornot 0.4.4 py_1 conda-forge
black 23.7.0 py39hcbf5309_1 conda-forge
bleach 6.0.0 pyhd8ed1ab_0 conda-forge
brotli 1.1.0 hcfcfb64_0 conda-forge
brotli-bin 1.1.0 hcfcfb64_0 conda-forge
brotli-python 1.1.0 py39h99910a6_0 conda-forge
bzip2 1.0.8 h8ffe710_4 conda-forge
ca-certificates 2023.7.22 h56e8100_0 conda-forge
certifi 2023.7.22 pyhd8ed1ab_0 conda-forge
cffi 1.15.1 py39h68f70e3_3 conda-forge
chardet 5.2.0 py39hcbf5309_0 conda-forge
charset-normalizer 3.2.0 pyhd8ed1ab_0 conda-forge
click 8.1.7 win_pyh7428d3b_0 conda-forge
cloudpickle 2.2.1 pyhd8ed1ab_0 conda-forge
colorama 0.4.6 pyhd8ed1ab_0 conda-forge
comm 0.1.4 pyhd8ed1ab_0 conda-forge
contourpy 1.1.0 py39h1f6ef14_0 conda-forge
cookiecutter 2.3.0 pyh1a96a4e_0 conda-forge
cryptography 41.0.3 py39hb6bd5e6_0 conda-forge
cycler 0.11.0 pyhd8ed1ab_0 conda-forge
debugpy 1.6.8 py39h99910a6_0 conda-forge
decorator 5.1.1 pyhd8ed1ab_0 conda-forge
defusedxml 0.7.1 pyhd8ed1ab_0 conda-forge
diff-match-patch 20230430 pyhd8ed1ab_0 conda-forge
dill 0.3.7 pyhd8ed1ab_0 conda-forge
docstring-to-markdown 0.12 pyhd8ed1ab_0 conda-forge
docutils 0.20.1 py39hcbf5309_0 conda-forge
entrypoints 0.4 pyhd8ed1ab_0 conda-forge
exceptiongroup 1.1.3 pyhd8ed1ab_0 conda-forge
executing 1.2.0 pyhd8ed1ab_0 conda-forge
flake8 6.0.0 pyhd8ed1ab_0 conda-forge
fonttools 4.42.1 py39ha55989b_0 conda-forge
freetype 2.12.1 h546665d_1 conda-forge
gettext 0.21.1 h5728263_0 conda-forge
glib 2.76.4 h12be248_0 conda-forge
glib-tools 2.76.4 h12be248_0 conda-forge
gst-plugins-base 1.22.5 h001b923_1 conda-forge
gstreamer 1.22.5 hb4038d2_1 conda-forge
icu 72.1 h63175ca_0 conda-forge
idna 3.4 pyhd8ed1ab_0 conda-forge
imagesize 1.4.1 pyhd8ed1ab_0 conda-forge
importlib-metadata 6.8.0 pyha770c72_0 conda-forge
importlib-resources 6.0.1 pyhd8ed1ab_0 conda-forge
importlib_metadata 6.8.0 hd8ed1ab_0 conda-forge
importlib_resources 6.0.1 pyhd8ed1ab_0 conda-forge
inflection 0.5.1 pyh9f0ad1d_0 conda-forge
intel-openmp 2023.2.0 h57928b3_49496 conda-forge
intervaltree 3.1.0 pyhd8ed1ab_1 conda-forge
ipykernel 6.25.2 pyh60829e3_0 conda-forge
ipython 8.15.0 pyh5737063_0 conda-forge
ipython_genutils 0.2.0 py_1 conda-forge
isort 5.12.0 pyhd8ed1ab_1 conda-forge
jaraco.classes 3.3.0 pyhd8ed1ab_0 conda-forge
jedi 0.18.2 pyhd8ed1ab_0 conda-forge
jellyfish 1.0.0 py39hf21820d_0 conda-forge
jinja2 3.1.2 pyhd8ed1ab_1 conda-forge
jsonschema 4.19.0 pyhd8ed1ab_1 conda-forge
jsonschema-specifications 2023.7.1 pyhd8ed1ab_0 conda-forge
jupyter_client 8.3.1 pyhd8ed1ab_0 conda-forge
jupyter_core 5.3.1 py39hcbf5309_0 conda-forge
jupyterlab_pygments 0.2.2 pyhd8ed1ab_0 conda-forge
keyring 24.2.0 py39hcbf5309_0 conda-forge
kiwisolver 1.4.5 py39h1f6ef14_0 conda-forge
krb5 1.20.1 heb0366b_0 conda-forge
lazy-object-proxy 1.9.0 py39ha55989b_0 conda-forge
lcms2 2.15 h3e3b177_1 conda-forge
lerc 4.0.0 h63175ca_0 conda-forge
libblas 3.9.0 18_win64_mkl conda-forge
libbrotlicommon 1.1.0 hcfcfb64_0 conda-forge
libbrotlidec 1.1.0 hcfcfb64_0 conda-forge
libbrotlienc 1.1.0 hcfcfb64_0 conda-forge
libcblas 3.9.0 18_win64_mkl conda-forge
libclang 16.0.6 default_heb8d277_1 conda-forge
libclang13 16.0.6 default_hc80b9e7_1 conda-forge
libdeflate 1.18 hcfcfb64_0 conda-forge
libffi 3.4.2 h8ffe710_5 conda-forge
libglib 2.76.4 he8f3873_0 conda-forge
libhwloc 2.9.2 default_haede6df_1009 conda-forge
libiconv 1.17 h8ffe710_0 conda-forge
libjpeg-turbo 2.1.5.1 hcfcfb64_0 conda-forge
liblapack 3.9.0 18_win64_mkl conda-forge
libogg 1.3.4 h8ffe710_1 conda-forge
libpng 1.6.39 h19919ed_0 conda-forge
libsodium 1.0.18 h8d14728_1 conda-forge
libspatialindex 1.9.3 h39d44d4_4 conda-forge
libsqlite 3.43.0 hcfcfb64_0 conda-forge
libtiff 4.5.1 h6c8260b_1 conda-forge
libvorbis 1.3.7 h0e60522_0 conda-forge
libwebp 1.3.1 hcfcfb64_0 conda-forge
libwebp-base 1.3.1 hcfcfb64_0 conda-forge
libxcb 1.15 hcd874cb_0 conda-forge
libxml2 2.11.5 hc3477c8_1 conda-forge
libzlib 1.2.13 hcfcfb64_5 conda-forge
m2w64-gcc-libgfortran 5.3.0 6 conda-forge
m2w64-gcc-libs 5.3.0 7 conda-forge
m2w64-gcc-libs-core 5.3.0 7 conda-forge
m2w64-gmp 6.1.0 2 conda-forge
m2w64-libwinpthread-git 5.0.0.4634.697f757 2 conda-forge
markdown-it-py 3.0.0 pyhd8ed1ab_0 conda-forge
markupsafe 2.1.3 py39ha55989b_0 conda-forge
matplotlib 3.7.2 py39hcbf5309_0 conda-forge
matplotlib-base 3.7.2 py39ha3e071c_0 conda-forge
matplotlib-inline 0.1.6 pyhd8ed1ab_0 conda-forge
mccabe 0.7.0 pyhd8ed1ab_0 conda-forge
mdurl 0.1.0 pyhd8ed1ab_0 conda-forge
mistune 3.0.1 pyhd8ed1ab_0 conda-forge
mkl 2022.1.0 h6a75c08_874 conda-forge
more-itertools 10.1.0 pyhd8ed1ab_0 conda-forge
msys2-conda-epoch 20160418 1 conda-forge
munkres 1.1.4 pyh9f0ad1d_0 conda-forge
mypy_extensions 1.0.0 pyha770c72_0 conda-forge
nbclient 0.8.0 pyhd8ed1ab_0 conda-forge
nbconvert 7.8.0 pyhd8ed1ab_0 conda-forge
nbconvert-core 7.8.0 pyhd8ed1ab_0 conda-forge
nbconvert-pandoc 7.8.0 pyhd8ed1ab_0 conda-forge
nbformat 5.9.2 pyhd8ed1ab_0 conda-forge
nest-asyncio 1.5.6 pyhd8ed1ab_0 conda-forge
numpy 1.25.2 py39h816b6a6_0 conda-forge
numpydoc 1.5.0 pyhd8ed1ab_0 conda-forge
openjpeg 2.5.0 ha2aaf27_2 conda-forge
openssl 3.1.2 hcfcfb64_0 conda-forge
packaging 23.1 pyhd8ed1ab_0 conda-forge
pandas 2.1.0 py39h32e6231_0 conda-forge
pandoc 3.1.3 h57928b3_0 conda-forge
pandocfilters 1.5.0 pyhd8ed1ab_0 conda-forge
paramiko 3.3.1 pyhd8ed1ab_0 conda-forge
parso 0.8.3 pyhd8ed1ab_0 conda-forge
pathspec 0.11.2 pyhd8ed1ab_0 conda-forge
pcre2 10.40 h17e33f8_0 conda-forge
pexpect 4.8.0 pyh1a96a4e_2 conda-forge
pickleshare 0.7.5 py_1003 conda-forge
pillow 10.0.0 py39ha9166d5_0 conda-forge
pip 23.2.1 pyhd8ed1ab_0 conda-forge
pkgutil-resolve-name 1.3.10 pyhd8ed1ab_0 conda-forge
platformdirs 3.10.0 pyhd8ed1ab_0 conda-forge
pluggy 1.3.0 pyhd8ed1ab_0 conda-forge
ply 3.11 py_1 conda-forge
prompt-toolkit 3.0.39 pyha770c72_0 conda-forge
prompt_toolkit 3.0.39 hd8ed1ab_0 conda-forge
psutil 5.9.5 py39ha55989b_0 conda-forge
pthread-stubs 0.4 hcd874cb_1001 conda-forge
pthreads-win32 2.9.1 hfa6e2cd_3 conda-forge
ptyprocess 0.7.0 pyhd3deb0d_0 conda-forge
pure_eval 0.2.2 pyhd8ed1ab_0 conda-forge
pycodestyle 2.10.0 pyhd8ed1ab_0 conda-forge
pycparser 2.21 pyhd8ed1ab_0 conda-forge
pydocstyle 6.3.0 pyhd8ed1ab_0 conda-forge
pyflakes 3.0.1 pyhd8ed1ab_0 conda-forge
pygments 2.16.1 pyhd8ed1ab_0 conda-forge
pylint 2.17.5 pyhd8ed1ab_0 conda-forge
pylint-venv 3.0.2 pyhd8ed1ab_0 conda-forge
pyls-spyder 0.4.0 pyhd8ed1ab_0 conda-forge
pynacl 1.5.0 py39h09fa780_2 conda-forge
pyparsing 3.0.9 pyhd8ed1ab_0 conda-forge
pyqt 5.15.9 py39hb77abff_4 conda-forge
pyqt5-sip 12.12.2 py39h99910a6_4 conda-forge
pyqtwebengine 5.15.9 py39h2f4a3f1_4 conda-forge
pysocks 1.7.1 pyh0701188_6 conda-forge
python 3.9.18 h4de0772_0_cpython conda-forge
python-dateutil 2.8.2 pyhd8ed1ab_0 conda-forge
python-fastjsonschema 2.18.0 pyhd8ed1ab_0 conda-forge
python-lsp-black 1.3.0 pyhd8ed1ab_0 conda-forge
python-lsp-jsonrpc 1.0.0 pyhd8ed1ab_0 conda-forge
python-lsp-server 1.7.4 pyhd8ed1ab_0 conda-forge
python-lsp-server-base 1.7.4 pyhd8ed1ab_0 conda-forge
python-slugify 8.0.1 pyhd8ed1ab_1 conda-forge
python-tzdata 2023.3 pyhd8ed1ab_0 conda-forge
python_abi 3.9 3_cp39 conda-forge
pytoolconfig 1.2.5 pyhd8ed1ab_0 conda-forge
pytz 2023.3.post1 pyhd8ed1ab_0 conda-forge
pywin32 304 py39h99910a6_2 conda-forge
pywin32-ctypes 0.2.2 py39hcbf5309_0 conda-forge
pyyaml 6.0.1 py39ha55989b_0 conda-forge
pyzmq 25.1.1 py39hea35a22_0 conda-forge
qdarkstyle 3.1 pyhd8ed1ab_0 conda-forge
qstylizer 0.2.2 pyhd8ed1ab_0 conda-forge
qt-main 5.15.8 h2c8576c_12 conda-forge
qt-webengine 5.15.8 h5b1ea0b_0 conda-forge
qtawesome 1.2.3 pyhd8ed1ab_0 conda-forge
qtconsole 5.4.4 pyhd8ed1ab_0 conda-forge
qtconsole-base 5.4.4 pyha770c72_0 conda-forge
qtpy 2.4.0 pyhd8ed1ab_0 conda-forge
referencing 0.30.2 pyhd8ed1ab_0 conda-forge
requests 2.31.0 pyhd8ed1ab_0 conda-forge
rich 13.5.1 pyhd8ed1ab_0 conda-forge
rope 1.9.0 pyhd8ed1ab_0 conda-forge
rpds-py 0.10.2 py39hf21820d_0 conda-forge
rtree 1.0.1 py39h09fdee3_2 conda-forge
setuptools 68.1.2 pyhd8ed1ab_0 conda-forge
sip 6.7.11 py39h99910a6_0 conda-forge
six 1.16.0 pyh6c4a22f_0 conda-forge
snowballstemmer 2.2.0 pyhd8ed1ab_0 conda-forge
sortedcontainers 2.4.0 pyhd8ed1ab_0 conda-forge
soupsieve 2.5 pyhd8ed1ab_1 conda-forge
sphinx 7.2.5 pyhd8ed1ab_0 conda-forge
sphinxcontrib-applehelp 1.0.7 pyhd8ed1ab_0 conda-forge
sphinxcontrib-devhelp 1.0.5 pyhd8ed1ab_0 conda-forge
sphinxcontrib-htmlhelp 2.0.4 pyhd8ed1ab_0 conda-forge
sphinxcontrib-jsmath 1.0.1 pyhd8ed1ab_0 conda-forge
sphinxcontrib-qthelp 1.0.6 pyhd8ed1ab_0 conda-forge
sphinxcontrib-serializinghtml 1.1.9 pyhd8ed1ab_0 conda-forge
spyder 5.4.5 py39hcbf5309_0 conda-forge
spyder-kernels 2.4.4 win_pyh7428d3b_0 conda-forge
stack_data 0.6.2 pyhd8ed1ab_0 conda-forge
tbb 2021.10.0 h91493d7_0 conda-forge
text-unidecode 1.3 py_0 conda-forge
textdistance 4.5.0 pyhd8ed1ab_0 conda-forge
three-merge 0.1.1 pyh9f0ad1d_0 conda-forge
tinycss2 1.2.1 pyhd8ed1ab_0 conda-forge
tk 8.6.12 h8ffe710_0 conda-forge
toml 0.10.2 pyhd8ed1ab_0 conda-forge
tomli 2.0.1 pyhd8ed1ab_0 conda-forge
tomlkit 0.12.1 pyha770c72_0 conda-forge
tornado 6.3.3 py39ha55989b_0 conda-forge
traitlets 5.9.0 pyhd8ed1ab_0 conda-forge
typing-extensions 4.7.1 hd8ed1ab_0 conda-forge
typing_extensions 4.7.1 pyha770c72_0 conda-forge
tzdata 2023c h71feb2d_0 conda-forge
ucrt 10.0.22621.0 h57928b3_0 conda-forge
ujson 5.7.0 py39h99910a6_0 conda-forge
unicodedata2 15.0.0 py39ha55989b_0 conda-forge
unidecode 1.3.6 pyhd8ed1ab_0 conda-forge
urllib3 2.0.4 pyhd8ed1ab_0 conda-forge
vc 14.3 h64f974e_17 conda-forge
vc14_runtime 14.36.32532 hfdfe4a8_17 conda-forge
vs2015_runtime 14.36.32532 h05e6639_17 conda-forge
watchdog 3.0.0 py39hcbf5309_0 conda-forge
wcwidth 0.2.6 pyhd8ed1ab_0 conda-forge
webencodings 0.5.1 py_1 conda-forge
whatthepatch 1.0.5 pyhd8ed1ab_0 conda-forge
wheel 0.41.2 pyhd8ed1ab_0 conda-forge
win_inet_pton 1.1.0 pyhd8ed1ab_6 conda-forge
wrapt 1.15.0 py39ha55989b_0 conda-forge
xorg-libxau 1.0.11 hcd874cb_0 conda-forge
xorg-libxdmcp 1.1.3 hcd874cb_0 conda-forge
xz 5.2.6 h8d14728_0 conda-forge
yaml 0.2.5 h8ffe710_2 conda-forge
yapf 0.40.1 pyhd8ed1ab_0 conda-forge
zeromq 4.3.4 h0e60522_1 conda-forge
zipp 3.16.2 pyhd8ed1ab_0 conda-forge
zstd 1.5.5 h12be248_0 conda-forge
I made a little video showing what I mean. It's here:
https://youtu.be/2HIiaCM5mr8
Thank you for the video and feedback @AstroALee ! I think the video shows in a quite clear way that for some reason the IPython console can get stuck until further interaction with Spyder is done. Could something be causing to stop/pause processing things from the kernel until something gets focus @ccordoba12 ? It's quite strange but maybe some sort of race condition to update states between things in the IPython console could be happening 🤔
Could something be causing to stop/pause processing things from the kernel until something gets focus
This reminded me of an important additional detail, which is that in the frozen/locked state, when you hit "restart kernel", the console output and plot window will flash up for a fraction of a second and then disappear when the kernel restarts.
I have the same issue for spyder 5.4.3 on Ubuntu. It's as shown in the youtube video posted by @AstroALee: when clicking into the field in the upper right showing the working directory, and hitting Enter, execution of the script goes forward. Please let me know in case in can provide useful information. Since this is on Linux Ubuntu, I am not sure if it's actually https://github.com/spyder-ide/spyder/issues/16400.
Hey guys, sorry for not replied back before but it seems some changes in the IPykernel package will solve this problem soon (I'm talking about https://github.com/ipython/ipykernel/pull/1212). If that's the case, then we'll bump our requirement on that package in our next version (5.5.2), to be released in a couple of weeks.
@gica3618, could you try this workaround https://github.com/spyder-ide/spyder/issues/16400#issuecomment-922412038 and report back? Thanks!
Thank you @ccordoba12. Now looking closer at https://github.com/spyder-ide/spyder/issues/16400, I think it's a different issue from the one I have. I can restart the kernel even when choosing Backend "Automatic". The problem I have is exactly like described here and shown in the video by @AstroALee. I tried the workaround anyway, but it didn't solve the issue.
Hi @ccordoba12, my understanding is that https://github.com/ipython/ipykernel/pull/1212 only solves the kernel hanging after an exception is raised and the kernel starts aborting future requests (which doesn't actually happen in my tests in SpyderShell ~~for reasons I don't yet understand~~ edit: because SpyderShell or some related widget/process sends an additional is_complete_request message to the kernel before the execute_request message - the eventloop exits due to the is_complete_request message, the abort stop method is called, and only then the execute_request message arrives).
This issue seems to be the kernel getting stuck (potentially in the eventloop) without an exception, which shouldn't really be impacted by my PR, but may be an adjacent problem? The Tkinter (on Mac and Linux) and Qt (on any platform) ipykernel eventloops are set up to exit on a ZMQ socket event, which a call to execute code should produce I think? From what I can see in the YouTube video, perhaps the execution of the file fails to exit the eventloop and then setting the working directory sends a ZMQ message and exits correctly, resuming file execution? If this was the problem I'd expect it to be reproducible on any platform where the eventloops exit on socket event rather than every kernel interval (so on any platform for Qt, and Linux and Mac for Tkinter). I wasn't able to reproduce this behaviour on Windows, so this may be something quite different? I don't have access to a Mac, but could maybe try on Ubuntu...
Hey @jdranczewski, thanks a lot for chiming in and help us to understand better this problem!
I wasn't able to reproduce this behaviour on Windows, so this may be something quite different?
Did you try it with the current IPykernel version? Or one that has the patch you developed in https://github.com/ipython/ipykernel/pull/1212? Just curious because it's not clear from your message.
I don't have access to a Mac, but could maybe try on Ubuntu...
Ok, we'd really appreciate that, thanks!
I tried the current, unpatched version of IPykernel. Will do more testing over the weekend!
I've had some luck reproducing this on Windows under Qt by spamming the run button, which occasionally makes a bizarre interaction of the Tornado io_loop, the kernel's message queue, and the GUI loop occur, with the run call being put on the queue but the GUI loop kicking in before the run call can be processed. This manifests in the same way (the run call is put into the console and nothing happens until the kernel is prodded to exit the GUI loop, for example by setting the working directory), but feels much more localised to me mashing the run button than the issue as described originally.
@James-F1dev could you specifically confirm that this happens on Windows under Tkinter for you? The Qt and Tkinter loops work in very different ways on Windows, so this would be very useful to know. I know you said that Tkinter is also affected in your original report, but I am very confused as to how this could happen under Tkinter on Windows (as it should return focus to the main kernel thread every 10ms or so), so thought I'd double-check.
I think there is a fairly simple fix to the way IPykernel schedules GUI loop runs that we could implement, but it would be useful to pinpoint the issue first so we know this is for sure the problem. @James-F1dev @AstroALee @gica3618 sorry for the mass ping, but you seem to be able to reproduce this - if you feel like doing small surgery on your ipykernel installation (most likely in lib/site-packages/ipykernel in your Python installation/virtual environment folder) it would be super useful to know if applying the changes from https://github.com/jdranczewski/ipykernel/commit/30da44ab4d355ce82750743ef3cd89bed7912f21 resolves the issue for you. Thanks!
Thanks for your help @jdranczewski! Let's ask @dalthviz to try your fix because he's one of our core developers and was also able to reproduce this problem.
@dalthviz, could you do that? Thanks!
@James-F1dev could you specifically confirm that this happens on Windows under Tkinter for you? The Qt and Tkinter loops work in very different ways on Windows, so this would be very useful to know. I know you said that Tkinter is also affected in your original report, but I am very confused as to how this could happen under Tkinter on Windows (as it should return focus to the main kernel thread every 10ms or so), so thought I'd double-check.
Hi @jdranczewski yes you are completely correct, it appears that Tkinter is not subject to this issue. Only automatic and Qt5 exhibit the behaviour described in my original post.
Tkinter sometimes fails to produce the plot window, but does not hang the kernel. This is resolved simply by running the script again, so it seems like a separate and less severe issue.
Thanks for looking at this.
Hi there, although I initially was unable to reproduce this, checked @jdranczewski spamming the run button way to reproduce this and I was indeed able to reproduce :+1:
Also, applying the patch to ipykernel to my installation indeed seems like fixes things :tada: I'm even able to see some output from matplotlib related with memory consumption in the console due to the amount of plots being open:
Thanks @dalthviz and @gica3618 for the confirmation!
The last thing left to be done then is to run our test suite against @jdranczewski pull request in IPykernel to check for possible regressions. I'll do that during the weekend.
This particular fix is not part of that PR yet, as it's a different issue (handling of call aborting in eventloops vs scheduling of eventloop calls), so I wasn't sure if I should bring it in there. I'll check with the maintainers over at IPykernel tomorrow (I still want to run some sanity checks) if they think this could be merged into one PR under the eventloop umbrella or if warrants a separate PR.