Ipython: Hängen nach dem Ausführen von pdb in einer Zelle, Kernel/Interrupt hilft nicht

Ich stoße auf das gleiche Problem.

Absolut, hier das gleiche. Dies ist ein königlicher Schmerz in den ziemlich empfindlichen Teilen meines Körpers. Wenn es eine bequeme Möglichkeit gäbe, pdb ohne die laufende Zelle zu stoppen, könnte dies gemildert werden. Alternativ wäre zumindest eine Möglichkeit, Ihre Arbeit vor dem Herunterfahren des Notebooks zu sichern, wichtig (zB trainiertes neuronales Netz und das Notebook stürzt beim Speichern nach 2000 Epochen ab).

Ich habe dieses Problem auch mit Jupyter Version 4.30, Python 3.6.2. Ein Neustart des Kernels scheint die einzige Möglichkeit zu sein, dieses Problem zu beheben.

Habe gerade eine 8-Stunden-Rechnung wegen dieser ... Zeit verloren, um wieder zu beginnen.

Ich habe gerade eine 64-Stunden-Rechnung verloren, auf der ich heute Ergebnisse präsentieren soll -.-

Niemand eine Lösung gefunden?

Wurde auch gerade davon gebissen. Wie debuggen Leute normalerweise in Jupyter Notebook? pdb zu benutzen ist wie mit einer Granate zu jonglieren :(

Bitte bitte bitte beheben Sie dies! Ich bekomme ständig dieses Problem.

Hier gilt das gleiche. Muss eine sehr lange Berechnung wiederholen

Ich auch.

bitte repariere jemand und ich zahle dir $5

@zsal Wenn Sie es ernst https://www.bountysource.com hinzufügen

Selbes Problem hier. Benötigen Sie eine Möglichkeit, einen außer Kontrolle geratenen Prozess oder einen Prozess, der auf eine Eingabe "wartet", zu unterbrechen und die Kontrolle zurückzugewinnen ... auch wenn ich nicht mehr zur Eingabeaufforderung komme.

Ich bin ein Neuling - Wie um alles in der Welt debuggen fortgeschrittene Programmierer in Notebooks? Sicherlich verwenden sie PDB nicht mit dieser "Zeitbombe" darin? Bitte teilen Sie Ihre Geheimnisse! :)

+1

+1

+1

+1

Hoch!
Dieses Problem bereitet mir seit Jahren jedes Mal, wenn ich pdb verwende und vergesse, aufzuhören, bevor ich die Zelle erneut starte.

Ich habe ein Kopfgeld auf BountySource erstellt. Vielleicht wird das endlich behoben, wenn wir genug Geld zusammenbekommen.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

+1

+1

Das hat mich seit Jahren verrückt gemacht.

Wie wäre es stattdessen mit IPython.core.debugger.Pdb ?

from IPython.core.debugger import Pdb; Pdb().set_trace()

(Oder %debug Magie kann zum Debuggen verwendet werden.)

Das zweimalige Ausführen von Pdb().set_trace() hat das gleiche Problem.

Ich untersuche das. Die grundlegende Funktionsweise von Interrupts besteht darin, dass sie (unter Unix) ein Signal an den Prozess senden, der dann KeyboardInterrupt auslöst.

Es scheint mehrere Probleme damit zu geben:

1. SIGINT unterbricht zeromq nicht. Dies wird hoffentlich von https://github.com/zeromq/pyzmq/pull/1368 behoben
2. Selbst wenn Zeromq unterbrechbar ist, glaube ich, dass pdb eine ganze Reihe von KeyboardInterrupt-Fangcode hat, der verhindert, dass er durchsickert. Dies kann vielleicht in IPython.core.debugger.Pdb behoben werden.

1. nicht korrekt ist, wird zeromq von SIGINT unterbrochen und löst KeyboardInterrupt aus, zumindest wenn der SIGINT-Handler selbst nicht überschrieben wurde.

@minrk ist richtig und ich lag falsch, sorry.

Um diesen Fix zu erhalten, muss Folgendes passieren:

• [x] Zusammenführen https://github.com/ipython/ipython/pull/12168
• [x] Neue IPython-Version
• [x] Zusammenführen https://github.com/ipython/ipykernel/pull/490
• [x] Zusammenführen https://github.com/ipython/ipykernel/pull/498
• [ ] Neue IPykernel-Version

Vielen Dank, dass Sie sich das angeschaut haben!!

Sobald es ein neues IPykernel-Release gibt, kann dieses als behoben geschlossen werden.

Fertig! Dies kann geschlossen werden.

import IPython
import ipykernel
print(IPython.__version__)
print(ipykernel.__version__)
IPython.core.debugger.set_trace()

7.15.0
5.3.0

``` 250 sys.stdout.flush()
251
--> 252 def __call__(self, result=None):
253 """Drucken mit History-Cache-Verwaltung.
254

--KeyboardInterrupt--
--KeyboardInterrupt--
```

KeyboardInterrupt scheint in meinem Fall nichts zu tun. Ist das das erwartete Verhalten?

Ich würde erwarten, dass das unterbricht. Ich werde sehen, ob ich reproduzieren kann. Das ist Windows, ja?

macOS 10.15.5

Python 3.6.2 (default, May  4 2018, 19:40:30)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin

Oh, das ist also nicht zu erwarten. Lassen Sie es mich wissen, wenn ich Informationen zur Klärung hinzufügen kann.

Pip-Liste
```Paketversion

Appnope 0.1.0
attrs 19.3.0
Rückruf 0.2.0
Bleichmittel 3.1.5
Dekorateur 4.4.2
defusedxml 0.6.0
Einstiegspunkte 0.3
ipykernel 5.3.0
ipython 7.15.0
ipython-genutils 0.2.0
ipywidgets 7.5.1
jedi 0.17.1
Jinja2 2.11.2
jsonschema 3.2.0
Jupyter 1.0.0
Jupyter-Client 6.1.3
Jupyter-Konsole 6.1.0
Jupyter-Kern 4.6.3
MarkupSafe 1.1.1
Verstimmung 0.8.4
nbconvert 5.6.1
nbformat 5.0.7
Notebook 6.0.3
Verpackung 20,4
pandocfilter 1.4.2
Parso 0.7.0
erwartet 4.8.0
Pickleshare 0.7.5
Pip 20.0.2
prometheus-client 0.8.0
Prompt-Toolkit 3.0.5
ptyprocess 0.6.0
Pygmente 2.6.1
pyparsing 2.4.7
hartnäckig 0.16.0
python-dateutil 2.8.1
pyzmq 19.0.1
qtconsole 4.7.5
QtPy 1.9.0
Send2Trash 1.5.0
Setuptools 46.0.0
sechs 1.15.0
terminado 0.8.3
Testpfad 0.4.4
Tornado 6.0.4
Eigenschaften 4.3.3
WC-Breite 0.2.5
Webencodings 0.5.1
Rad 0.34.2
Widgetsnbeextension 3.5.1```

Bei mir trat das Problem auch nach dem Update auf. Siehe auch auf den Remote-Linux-Rechenknoten, die ich für die Arbeit verwende:

import IPython
import ipykernel
import os
import platform

print(IPython.__version__)
print(ipykernel.__version__)
print(os.name,platform.system(),platform.release())
IPython.core.debugger.set_trace()

7.15.0
5.3.0
posix Linux 4.19.94-300.el7.x86_64

Arbeiten Sie derzeit in einer ziemlich sperrigen Umgebung, können Sie also nicht ausschließen, dass einige Abhängigkeiten dies verursachen? Ich kann versuchen zu sehen, ob sich der Fehler auch in einer minimalen Umgebung reproduziert, wenn das nützlich wäre?

Dies erfordert einen noch nicht veröffentlichten Master von IPykernel.