Ipython: Pendure depois de executar o pdb em uma célula, Kernel / Interrupt não ajuda

Estou tendo o mesmo problema.

Com certeza, o mesmo aqui. É uma dor real nas partes bastante sensíveis do meu corpo. Se existisse uma maneira conveniente de interromper o pdb sem a célula em execução, isso poderia ser atenuado. Alternativamente, pelo menos uma maneira de salvar seu trabalho antes de desligar o notebook seria importante (por exemplo, rede neural treinada e o notebook trava ao salvar após 2000 épocas).

Também tenho esse problema com o Jupyter versão 4.30, Python 3.6.2. Reiniciar o kernel parece ser a única maneira de lidar com esse problema.

Acabei de perder um cálculo de 8 horas devido a isso ... hora de começar de novo.

Acabei de perder um cálculo de 64 horas no qual devo apresentar os resultados hoje -.-

Ninguém encontrou uma solução?

Também fui mordido por isso. Como as pessoas costumam depurar no notebook jupyter? Usar o PDB é como fazer malabarismo com uma granada :(

Por favor, corrija isso! Estou constantemente tendo esse problema.

Mesmo aqui. Tem que refazer um cálculo muito longo

mesmo aqui.

alguém por favor conserte e eu te pagarei $ 5

@zsal Se você estiver falando sério, pode adicionar este é o problema em https://www.bountysource.com

Mesmo problema aqui. Preciso de uma maneira de interromper um processo descontrolado ou que está "aguardando" uma entrada e obter o controle de volta ... mesmo que eu não consiga mais acessar o prompt de entrada.

Eu sou um newby - Como os programadores avançados depuram em notebooks? Certamente eles não usam PDB com esta "bomba-relógio" nele? Por favor, compartilhe seus segredos! :)

+1

+1

+1

+1

Acima!
Este problema tem sido uma dor para mim há anos, sempre que uso o PDB e me esqueço de sair antes de executar novamente o celular.

Eu criei uma recompensa no BountySource. Talvez isso seja finalmente consertado se conseguirmos juntar dinheiro suficiente.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

+1

+1

Isso me deixou louco por anos.

Que tal usar IPython.core.debugger.Pdb vez disso?

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

(Ou %debug magic pode ser usado para depuração.)

Executar Pdb().set_trace() duas vezes causa o mesmo problema.

Estou investigando isso. A maneira básica como as interrupções funcionam é que elas (no Unix) enviam um sinal para o processo, que então dispara o KeyboardInterrupt.

Parece haver vários problemas com isso:

1. SIGINT não interromperá zeromq. Esperançosamente, isso foi corrigido por https://github.com/zeromq/pyzmq/pull/1368
2. Mesmo quando o zeromq é interrompível, acredito que pdb tem um monte de código de captura de interrupção do teclado que o impede de se infiltrar. Isso talvez possa ser corrigido em IPython.core.debugger.Pdb .

1. não for preciso, zeromq é interrompido por SIGINT e gera KeyboardInterrupt, pelo menos a menos que o próprio manipulador SIGINT tenha sido substituído.

@minrk está correto e eu estava errado, desculpe.

Para obter essa correção, o seguinte precisa acontecer:

• [x] Merge https://github.com/ipython/ipython/pull/12168
• [x] Nova versão IPython
• [x] Merge https://github.com/ipython/ipykernel/pull/490
• [x] Merge https://github.com/ipython/ipykernel/pull/498
• [] Nova versão do IPykernel

Muito obrigado por investigar isso !!

Assim que houver uma nova versão do IPykernel, isso pode ser fechado como consertado.

Feito! Isso pode ser fechado.

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 "" "Impressão com gerenciamento de cache de histórico.
254

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

KeyboardInterrupt parece não fazer nada no meu caso. É esse o comportamento esperado?

Eu esperaria que isso fosse interrompido. Vou ver se consigo reproduzir. Este é o Windows, sim?

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, então isso não é esperado. Deixe-me saber se houver alguma informação que eu possa acrescentar para esclarecer.

lista de pip
`` `Versão do pacote

appnope 0.1.0
atrs 19.3.0
backcall 0.2.0
alvejante 3.1.5
decorador 4.4.2
defusedxml 0.6.0
pontos de entrada 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-console 6.1.0
jupyter-core 4.6.3
MarkupSafe 1.1.1
mistune 0.8.4
nbconvert 5.6.1
nbformat 5.0.7
notebook 6.0.3
embalagem 20,4
pandocfilters 1.4.2
parso 0.7.0
pexpect 4.8.0
pickleshare 0.7.5
pip 20.0.2
cliente-prometheus 0.8.0
prompt-toolkit 3.0.5
ptyprocess 0.6.0
Pigmentos 2.6.1
pyparsing 2.4.7
pyrsistent 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
seis 1.15.0
terminado 0.8.3
testpath 0.4.4
tornado 6.0.4
traitlets 4.3.3
wcwidth 0.2.5
webencodings 0.5.1
roda 0.34.2
widgetsnbextension 3.5.1```

Para mim, o problema também persistiu após a atualização. Também nos nós de computação remotos do Linux que uso para trabalhar, consulte:

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

Atualmente trabalhando em um ambiente bastante volumoso, não é possível descartar algumas dependências que podem estar causando isso? Posso tentar ver se o erro também se reproduz em um ambiente mínimo se isso seria útil?

Isso precisa de um master de IPykernel que ainda não foi lançado.