ipython: Hang after running pdb in a cell, Kernel/Interrupt doesn't help

If you debug a cell via pdb, then don’t quit it before rerunning the cell, you can’t get back to your IPython environment. Reproduce it via Test case for pdb hang in Jupyter notebook. Here’s a screenshot:

pdb_resists_kernel_interrupt ipynb

For the record and search engines, to hang your notebook:

  • Run the following cell
  • Do not “quit” via the pdb prompt
  • Then run it again.
def test():
    import pdb; pdb.set_trace()  # XXX BREAKPOINT
    return 0

test()

Note that Kernel/Interupt doesn’t help. You can save the notebook, but to run cells again, you need to restart the kernel, at which point “All variables will be lost”

This happens to me not infrequently if I am searching thru the rest of the notebook for hints on how to debug the cell, then forget to quit before changing the cell and running it again. Yes, I can be more careful, but others have the same experience. Thanks to @wmayner for a convenient test case described at #3400.

I’m running Jupyter notebook 4.3.1 on Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] Kernel Information: Python 3.4.3 (default, Nov 17 2016, 01:08:31)

Input from @takluyver at #10499

pdb runs in the same process, and we do know when it’s expecting input. I think it needs someone to do the work so that when the HTML input box is removed in the frontend, a message is sent back to the kernel which will raise EOFError. That may need a new message type, or we could do it as a metadata field on the existing stdin reply message.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 73
  • Comments: 34 (9 by maintainers)

Most upvoted comments

Just got bitten by this as well. How do people typically debug in jupyter notebook? Using pdb is like juggling a grenade 😦

I am running into the same problem.

Absolutely, same here. This is a royal pain in the rather sensitive parts of my body. If a convenient way to stop pdb from without the running cell existed this could be alleviated. Alternatively, at least a way of saving your work before shutting down the notebook would be important (e.g. trained neural network and the notebook crashes on save after 2000 epochs).

As soon as there is a new IPykernel release, this can be closed as fixed.

To get this fix in, the following needs to happen:

Just lost a 64 hour calculation on which I’m meant to be presenting results today -.-

No one found a solution?

I also have this issue, with Jupyter version 4.30, Python 3.6.2. Restarting the kernel appears to be the only way to handle this issue.

someone please fix and I will pay you $5

I created a bounty on BountySource. Maybe this will finally be fixed if we can gather enough money. https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

I am investigating this. The basic way interrupts work is that they (on Unix) send a signal to the process, which then raises KeyboardInterrupt.

There are appear to be multiple issues with this happening:

  1. SIGINT won’t interrupt zeromq. This is fixed hopefully by https://github.com/zeromq/pyzmq/pull/1368
  2. Even once zeromq is interruptible, I believe pdb has a whole bunch of KeyboardInterrupt-catching code that prevents it from percolating up. This may perhaps be fixable in IPython.core.debugger.Pdb.

Running Pdb().set_trace() twice has the same issue.