Spyder: TimeoutError when starting a kernel still poping out

Created on 20 Mar 2020 · 17Comments · Source: spyder-ide/spyder

Description

What steps will reproduce the problem?

I started Spyder and hovered over one of those red "X" icons in the editor margin to see the tooltip, and this dialog box appeared

Traceback

  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder\plugins\ipythonconsole\plugin.py", line 1083, in set_spyder_breakpoints
    cl.shellwidget.set_spyder_breakpoints()
  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder\plugins\ipythonconsole\widgets\debugging.py", line 143, in set_spyder_breakpoints
    CONF.get('run', 'breakpoints', {}))
  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder_kernels\comms\commbase.py", line 538, in __call__
    call_dict, call_data, self._comm_id)
  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder\plugins\ipythonconsole\comms\kernelcomm.py", line 130, in _get_call_return_value
    with self.comm_channel_manager(comm_id, queue_message=not interrupt):
  File "C:\Users\AlexStoll\Anaconda3\lib\contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder\plugins\ipythonconsole\comms\kernelcomm.py", line 87, in comm_channel_manager
    timeout)
  File "C:\Users\AlexStoll\Anaconda3\lib\site-packages\spyder\plugins\ipythonconsole\comms\kernelcomm.py", line 168, in _wait
    raise TimeoutError(timeout_msg)
TimeoutError: Timeout while waiting for comm port.

Versions

Spyder version: 4.1.1
Python version: 3.6.8
Qt version: 5.9.6
PyQt5 version: 5.9.2
Operating System: Windows 10

Dependencies


# Mandatory:
atomicwrites >=1.2.0           :  1.3.0 (OK)
chardet >=2.0.0                :  3.0.4 (OK)
cloudpickle >=0.5.0            :  1.3.0 (OK)
diff_match_patch >=20181111    :  20181111 (OK)
intervaltree                   :  None (OK)
IPython >=4.0                  :  7.13.0 (OK)
jedi =0.15.2                   :  0.15.2 (OK)
nbconvert >=4.0                :  5.6.1 (OK)
numpydoc >=0.6.0               :  0.9.2 (OK)
paramiko >=2.4.0               :  2.7.1 (OK)
parso =0.5.2                   :  0.5.2 (OK)
pexpect >=4.4.0                :  4.8.0 (OK)
pickleshare >=0.4              :  0.7.5 (OK)
psutil >=5.3                   :  5.7.0 (OK)
pygments >=2.0                 :  2.6.1 (OK)
pylint >=0.25                  :  2.4.4 (OK)
pyls >=0.31.9;<0.32.0          :  0.31.9 (OK)
qdarkstyle >=2.8               :  2.8 (OK)
qtawesome >=0.5.7              :  0.7.0 (OK)
qtconsole >=4.6.0              :  4.7.1 (OK)
qtpy >=1.5.0                   :  1.9.0 (OK)
rtree >=0.8.3                  :  0.9.3 (OK)
sphinx >=0.6.6                 :  2.4.0 (OK)
spyder_kernels >=1.9.0;<1.10.0 :  1.9.0 (OK)
watchdog                       :  None (OK)
zmq >=17                       :  18.1.1 (OK)

# Optional:
cython >=0.21                  :  None (OK)
matplotlib >=2.0.0             :  None (OK)
numpy >=1.7                    :  1.18.1 (OK)
pandas >=0.13.1                :  None (OK)
scipy >=0.17.0                 :  1.4.1 (OK)
sympy >=0.7.3                  :  None (OK)

IPython Console Bug

Source

N22YF

Most helpful comment

I tried a lot things to reproduce this but I couldn't. Let's wait to see if more people reports it.

ccordoba12 on 23 Mar 2020

👍2

All 17 comments

I tried a lot things to reproduce this but I couldn't. Let's wait to see if more people reports it.

ccordoba12 on 23 Mar 2020

👍2

From issue #12037: steps to reproduce:

Launch python -m spyder_kernels.console on remote host
Conect to remote kernel in spyder using ssh creds and kernel json.

ccordoba12 on 30 Mar 2020

I experienced the same issue Spyder 4.1 / Python 3.7

File "E:DEVenvsLORAlibsite-packagesspyderpluginsipythonconsoleplugin.py", line 569, in update_path
shell.update_syspath(path_dict, new_path_dict)
File "E:DEVenvsLORAlibsite-packagesspyderpluginsipythonconsolewidgetsshell.py", line 223, in update_syspath
blocking=False).update_syspath(path_dict, new_path_dict)
File "E:DEVenvsLORAlibsite-packagesspyder_kernelscommscommbase.py", line 538, in __call__
call_dict, call_data, self._comm_id)
File "E:DEVenvsLORAlibsite-packagesspyderpluginsipythonconsolecommskernelcomm.py", line 130, in _get_call_return_value
with self.comm_channel_manager(comm_id, queue_message=not interrupt):
File "E:DEVenvsLORAlibcontextlib.py", line 112, in __enter__
return next(self.gen)
File "E:DEVenvsLORAlibsite-packagesspyderpluginsipythonconsolecommskernelcomm.py", line 87, in comm_channel_manager
timeout)
File "E:DEVenvsLORAlibsite-packagesspyderpluginsipythonconsolecommskernelcomm.py", line 168, in _wait
raise TimeoutError(timeout_msg)
TimeoutError: Timeout while waiting for comm port.

ERIO17 on 1 Apr 2020

@impact27, we really need your help with this one. I don't understand why it's still happening.

ccordoba12 on 12 Apr 2020

I don't have access to a remote host now to try it but if it happens consistently I think it means the port used for comms is blocked by the firewall. This shouldn't happen in a local host.

impact27 on 13 Apr 2020

As I said in the other issue this is happening for me when running slow tests locally all the time and it happens randomly on CI systems so there is something going on beyond "your system is too slow".

goanpeca on 13 Apr 2020

@impact27, I think we need to show a kernel error message when this happens in the console, instead of raising a TimeoutError that people is compelled to report here.

ccordoba12 on 13 Apr 2020

As I said in the other issue this is happening for me when running slow tests locally all the time and it happens randomly on CI systems so there is something going on beyond "your system is too slow".

Yes the system would need to be very slow for the kernel to not launch in 45 seconds. There are no steps to reproduce so it is a bit hard for me to do a better guess. The local tests are passing on my machine.

Issue #12037: I think this might be related to the firewall blocking the port used for comms.

Issue #12247: I think this is unrelated to comms and happens because the kernel is not launching somehow (Not in 45 seconds anyway). The line where the tests are crashing is already a line that was added to handle slow-starting kernels in tests. It would be useful if you could confirm that by looking at the failing test and checking if the kernel comes up in a reasonable amount of time for the failing test. In practice I would record the screen to avoid having to look at the computer during the entire test procedure. As far as I know the tests only fail during the setups of the tests in test_mainwindow.py. Can you:
1 - Confirm whether the local tests only fail during the test setup in test_mainwindow.py?
2 - Send a video of a failing test setup if that is the case?

@impact27, I think we need to show a kernel error message when this happens in the console, instead of raising a TimeoutError that people is compelled to report here.

We could have a message saying:
"The communication with the kernel is unresponsive. Try restarting the kernel if this persists."

impact27 on 13 Apr 2020

Will do late today! Thanks. The tests that fails is not always the same, it just changes everytime I run the slow test suite.

goanpeca on 13 Apr 2020

Will do late today! Thanks. The tests that fails is not always the same, it just changes everytime I run the slow test suite.

Yes I see but I think that what is failing is the setup for the tests, So any test in test_mainwindow.py might fail, but always during the setup.

impact27 on 13 Apr 2020

might fail, but always during the setup.

Will check and let you know ;-)

goanpeca on 13 Apr 2020

I tried a lot things to reproduce this but I couldn't. Let's wait to see if more people reports it.

I ve got the same issue but not getting what and where is the problem...

Usman336 on 10 May 2020

I tried a lot things to reproduce this but I couldn't. Let's wait to see if more people reports it.

I ve got the same issue but not getting what and where is the problem...

My understanding is that the kernel dies for some reason and then the frontend can not communicate to the kernel any more, raising the TimeoutError. Is that the case for you? was the kernel alive when the error rose?

impact27 on 11 May 2020

I tried a lot things to reproduce this but I couldn't. Let's wait to see if more people reports it.

I ve got the same issue but not getting what and where is the problem...

My understanding is that the kernel dies for some reason and then the frontend can not communicate to the kernel any more, raising the TimeoutError. Is that the case for you? was the kernel alive when the error rose?

no the kernel was dead...

Usman336 on 11 May 2020

no the kernel was dead...

Do you know why the kernel was dead?

impact27 on 12 May 2020

no the kernel was dead...

Do you know why the kernel was dead?

well in IPython console this message appears and the kernel wasn't alive at the time and restarting it clearly states that it died...
However, I wrote this code a little earlier as follows...
if len(sys.argv) != 2:
sys.exit("Usage: txt file needed")
m = solve(sys.argv[1])
but changed it into something else that doesnt involve file handling...
after a while this error starts to appear...

Usman336 on 12 May 2020

After reviewing this thread that spyder-bot indicated was a duplicate of my #12900, I recalled that when I first loaded Spyder today (fresh install in a new venv, also; started via Anaconda) the kernel did not start, I had some kind of waiting error that I didn't take much note of (using "restart kernel" in the dropdown resolved it). After doing that, I had closed spyder and reopened it manually from command line with my new venv active, trying to determine if the fresh install in a different venv should load the files I had active in my previous venv or not (apparently it does).

Didn't know whether this might be relevant information so I figured I should include it.