Ipython: Зависание после запуска pdb в ячейке, ядро ​​/ прерывание не помогает

Я столкнулся с той же проблемой.

Абсолютно то же самое и здесь. Это королевская боль в довольно чувствительных частях моего тела. Если бы существовал удобный способ остановить pdb без работающей ячейки, это можно было бы облегчить. В качестве альтернативы, будет важен, по крайней мере, способ сохранения вашей работы перед выключением ноутбука (например, обученная нейронная сеть и сбой ноутбука при сохранении после 2000 эпох).

У меня тоже есть эта проблема с Jupyter версии 4.30, Python 3.6.2. Похоже, что перезапуск ядра - единственный способ решить эту проблему.

Просто потерял 8-часовой расчет из-за этого ... пора начинать заново.

Только что потерял 64-часовой расчет, по которому я должен представить результаты сегодня -.-

Никто не нашел решения?

Просто меня это тоже укусило. Как люди обычно отлаживают в jupyter notebook? Использование pdb похоже на жонглирование гранатой :(

Пожалуйста, исправьте это! У меня постоянно возникает эта проблема.

То же самое. Придется переделывать очень длинный расчет

то же самое.

кто-нибудь, пожалуйста, исправьте, и я заплачу вам 5 долларов

@zsal Если вы серьезно, вы можете добавить эту проблему на https://www.bountysource.com

Здесь та же проблема. Нужен способ прервать неконтролируемый процесс или процесс, который «ожидает» ввода, и вернуть управление ... даже если я больше не могу получить доступ к приглашению ввода.

Я новичок - Как, черт возьми, продвинутые программисты отлаживают в ноутбуках? Неужели они не используют PDB с этой "бомбой замедленного действия"? Пожалуйста, поделитесь своими секретами! :)

+1

+1

+1

+1

Вверх!
Эта проблема была для меня головной болью в течение многих лет каждый раз, когда я использую pdb и забываю завершить работу перед повторным запуском ячейки.

Я создал награду на BountySource. Может быть, это, наконец, исправят, если мы соберем достаточно денег.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

+1

+1

Это сводило меня с ума на долгие годы.

Как насчет использования вместо этого IPython.core.debugger.Pdb ?

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

(Или для отладки можно использовать магию %debug .)

Выполнение Pdb().set_trace() дважды вызывает ту же проблему.

Я исследую это. Основной способ работы прерываний заключается в том, что они (в Unix) посылают сигнал процессу, который затем вызывает KeyboardInterrupt.

Похоже, что с этим случается несколько проблем:

1. SIGINT не прерывает работу zeromq. Надеюсь, это исправлено https://github.com/zeromq/pyzmq/pull/1368
2. Я считаю, что даже если zeromq можно прерывать, в pdb есть целая куча кода, перехватывающего KeyboardInterrupt, который предотвращает его просачивание. Возможно, это можно исправить в IPython.core.debugger.Pdb .

1. неточно, zeromq прерывается SIGINT и вызывает KeyboardInterrupt, по крайней мере, если сам обработчик SIGINT не был переопределен.

@minrk правильный, и я ошибался, извините.

Чтобы установить это исправление, должно произойти следующее:

• [x] Объединить https://github.com/ipython/ipython/pull/12168
• [x] Новый выпуск IPython
• [x] Объединить https://github.com/ipython/ipykernel/pull/490
• [x] Объединить https://github.com/ipython/ipykernel/pull/498
• [] Новый выпуск IPykernel

Большое спасибо, что изучили это !!

Как только появится новый выпуск IPykernel, его можно будет закрыть как исправленный.

Выполнено! Это можно закрыть.

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 "" "Печать с управлением кешем истории.
254

--KeyboardInterrupt--
--KeyboardInterrupt--
`` ''

KeyboardInterrupt в моем случае ничего не делает. Это ожидаемое поведение?

Я ожидал, что это прервется. Я посмотрю, смогу ли я воспроизвести. Это винда, да?

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

Ой, так этого и не ожидалось. Дайте мне знать, если есть какая-то информация, которую я могу добавить, чтобы уточнить.

список пунктов
Версия пакета

appnope 0.1.0
attrs 19.3.0
обратный звонок 0.2.0
отбеливатель 3.1.5
декоратор 4.4.2
defusedxml 0.6.0
точки входа 0,3
ipykernel 5.3.0
ipython 7.15.0
ipython-genutils 0.2.0
ipywidgets 7.5.1
джедаи 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 4.6.3
MarkupSafe 1.1.1
mistune 0.8.4
nbconvert 5.6.1
nbformat 5.0.7
ноутбук 6.0.3
упаковка 20,4
pandocfilters 1.4.2
парсо 0.7.0
pexpect 4.8.0
соленый огурец 0,7.5
пункт 20.0.2
Прометей-клиент 0.8.0
подсказка-инструментарий 3.0.5
ptyprocess 0.6.0
Пигменты 2.6.1
pyparsing 2.4.7
пирсистентный 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
шесть 1.15.0
terminado 0.8.3
testpath 0.4.4
торнадо 6.0.4
черты 4.3.3
wcwidth 0.2.5
веб-кодировки 0.5.1
колесо 0.34.2
виджетыnbextension 3.5.1 ''

Для меня проблема также сохранилась после обновления. Также об удаленных вычислительных узлах Linux, которые я использую для работы, см.

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

В настоящее время работаете в довольно громоздкой среде, поэтому не можете исключить, что это могут быть какие-то зависимости? Я могу попытаться увидеть, воспроизводится ли ошибка в минимальной среде, если это будет полезно?

Для этого нужен мастер IPykernel, который еще не выпущен.