Ipython: Se bloquer après avoir exécuté pdb dans une cellule, Kernel/Interrupt n'aide pas

Je rencontre le même problème.

Absolument, pareil ici. C'est une douleur royale dans les parties assez sensibles de mon corps. S'il existait un moyen pratique d'arrêter pdb sans la cellule en cours d'exécution, cela pourrait être atténué. Alternativement, au moins un moyen de sauvegarder votre travail avant d'arrêter le notebook serait important (par exemple, un réseau neuronal formé et le notebook se bloque lors de la sauvegarde après 2000 époques).

J'ai également ce problème, avec Jupyter version 4.30, Python 3.6.2. Le redémarrage du noyau semble être le seul moyen de résoudre ce problème.

Je viens de perdre un calcul de 8 heures à cause de cela... il est temps de recommencer.

Je viens de perdre un calcul de 64 heures sur lequel je suis censé présenter les résultats aujourd'hui -.-

Personne n'a trouvé de solution ?

Je viens de me faire mordre par ça aussi. Comment les gens déboguent-ils généralement dans jupyter notebook ? Utiliser pdb, c'est comme jongler avec une grenade :(

S'il vous plaît s'il vous plaît s'il vous plaît corriger cela! Je reçois constamment ce problème.

Pareil ici. Faut refaire un très long calcul

pareil ici.

quelqu'un s'il vous plaît réparer et je vous paierai 5 $

@zsal Si vous êtes sérieux, vous pouvez ajouter ce problème sur https://www.bountysource.com

Même problème ici. Besoin d'un moyen d'interrompre un processus qui s'emballe ou qui "attend" la saisie et de reprendre le contrôle ... même si je ne peux plus accéder à l'invite de saisie.

Je suis un débutant - Comment diable les programmeurs avancés déboguent-ils dans les ordinateurs portables ? Sûrement ils n'utilisent pas PDB avec cette "bombe à retardement" dedans ? S'il vous plaît, partagez vos secrets! :)

+1

+1

+1

+1

En haut!
Ce problème est pénible pour moi depuis des années maintenant chaque fois que j'utilise pdb et que j'oublie de quitter avant de relancer la cellule.

J'ai créé une prime sur BountySource. Peut-être que cela sera enfin corrigé si nous pouvons rassembler suffisamment d'argent.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

+1

+1

Cela m'a rendu fou pendant des années.

Que diriez-vous d'utiliser IPython.core.debugger.Pdb place ?

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

(Ou la magie %debug peut être utilisée pour le débogage.)

Exécuter Pdb().set_trace() deux fois a le même problème.

J'étudie cela. Le fonctionnement de base des interruptions est qu'elles (sous Unix) envoient un signal au processus, qui déclenche alors KeyboardInterrupt.

Il semble y avoir plusieurs problèmes avec ce qui se passe :

1. SIGINT n'interrompra pas zeromq. Ceci est résolu, espérons-le, par https://github.com/zeromq/pyzmq/pull/1368
2. Même une fois que zeromq est interruptible, je crois que pdb a tout un tas de code attrapant KeyboardInterrupt qui l'empêche de s'infiltrer. Cela peut peut-être être corrigé dans IPython.core.debugger.Pdb .

1. n'est pas précis, zeromq est interrompu par SIGINT et déclenche KeyboardInterrupt, du moins à moins que le gestionnaire SIGINT n'ait lui-même été remplacé.

@minrk a raison et je me suis trompé, désolé.

Pour obtenir ce correctif, les étapes suivantes doivent se produire :

• [x] Fusionner https://github.com/ipython/ipython/pull/12168
• [x] Nouvelle version d'IPython
• [x] Fusionner https://github.com/ipython/ipykernel/pull/490
• [x] Fusionner https://github.com/ipython/ipykernel/pull/498
• [ ] Nouvelle version d'IPykernel

Merci beaucoup d'avoir étudié cela !!

Dès qu'il y a une nouvelle version d'IPykernel, celle-ci peut être fermée comme corrigé.

Terminé! Celui-ci peut être fermé.

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 """Impression avec gestion du cache de l'historique.
254

--KeyboardInterruption--
--KeyboardInterrupt--
```

KeyboardInterrupt semble ne rien faire dans mon cas. Est-ce le comportement attendu ?

Je m'attendrais à ce que cela interrompe. Je vais voir si je peux reproduire. C'est Windows, non ?

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, donc ce n'est pas prévu. Faites-moi savoir s'il y a des informations que je peux ajouter pour clarifier.

liste de pépins
```Version du paquet

Appnope 0.1.0
attr 19.3.0
rappel 0.2.0
eau de javel 3.1.5
décorateur 4.4.2
defusedxml 0.6.0
points d'entrée 0.3
ipykernel 5.3.0
python 7.15.0
ipython-genutils 0.2.0
ipywidgets 7.5.1
jedi 0.17.1
Jinja2 2.11.2
schéma json 3.2.0
jupyter 1.0.0
jupyter-client 6.1.3
jupyter-console 6.1.0
jupyter-core 4.6.3
MarkupSafe 1.1.1
brouillage 0.8.4
nbconvert 5.6.1
nbformat 5.0.7
cahier 6.0.3
emballage 20,4
pandocfiltres 1.4.2
parso 0.7.0
attente 4.8.0
cornichon 0.7.5
pépin 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
pyrsistant 0.16.0
python-dateutil 2.8.1
pyzmq 19.0.1
qtconsole 4.7.5
QtPy 1.9.0
Send2Trash 1.5.0
outils de configuration 46.0.0
six 1.15.0
Terminé 0.8.3
chemin de test 0.4.4
tornade 6.0.4
traitlets 4.3.3
largeur d'eau 0.2.5
codages Web 0.5.1
roue 0.34.2
widgetsnbextension 3.5.1```

Pour moi, le problème a également persisté après la mise à jour. Également sur les nœuds de calcul Linux distants que j'utilise pour le travail, voir :

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

Vous travaillez actuellement dans un environnement assez volumineux, vous ne pouvez donc pas exclure que certaines dépendances pourraient en être la cause ? Je peux essayer de voir si l'erreur se reproduit également dans un environnement minimal si cela serait utile ?

Cela nécessite un maître d'IPykernel qui n'a pas encore été publié.