py.user.next
В каком классе этот метод notify() определён?
class CS11mainApp(QtGui.QApplication):
py.user.next
Перед этой строкой с return выведи type(self) в консоль.
<class '__main__.CS11mainApp'>
Вставь отдельный print в except часть (в каждой except части должен быть свой print). Посмотри, не входит ли оно в except перед падением.
py.user.nextВставил, в except перед падением не входит.
Вставь отдельный print в except часть (в каждой except части должен быть свой print). Посмотри, не входит ли оно в except перед падением.
То есть уже на строчке print(dir(receiver)) произошел сегфолт…
Может, это баг самого питона? А то всё грешил на Qt и PyQt…
Это не баг python-а, а то о чём я думал. receiver это питоновская обёртка над объектом Qt-а. При некоторых ошибках может получиться так что Qt-объект удалён, а receiver ещё жива. В это случае при любом обращении к receiver происходит ошибка сегментирования.
https://habrahabr.ru/post/210304/
RodegastСпасибо! Осталось искать где именно косяк в коде… receiver может ли как-то подсказать?
Это не баг python-а, а то о чём я думал. receiver это питоновская обёртка над объектом Qt-а. При некоторых ошибках может получиться так что Qt-объект удалён, а receiver ещё жива. В это случае при любом обращении к receiver происходит ошибка сегментирования.
https://habrahabr.ru/post/210304/
receiver тебе ничем не поможет. Посмотри с каким сигналом он приходит, а потом просмотри все emit-ы которые этот сигнал генерируют. Наверняка в каком-то из них касяк.
VadyПоправлю: даже с закомментированным переопределенным методом сегфолты все-таки происходят, если с программой работать намного дольше. Действительно, источник надо искать в другом месте…
И, кстати, если весь этот переопределенный метод def notify… закомментировать, то сегфолты уже не замечаю, да и сама программа стала шустрее работать!
RodegastПризнаю: я не гуру в вопросах дебаггинга, источника сигналов из 2000 файлов пока найти не удалось. Продолжаю поиски через принты построчно…
receiver тебе ничем не поможет. Посмотри с каким сигналом он приходит, а потом просмотри все emit-ы которые этот сигнал генерируют. Наверняка в каком-то из них касяк.
VadyСначала через принты, но потом дойдёшь до дебаггера. Хотя разницы нет, просто дебаггер быстрее и там много всего автоматизировано (поиск функции, постановка и снятие брейкпоинтов, быстрый проход до брейкпоинта). Ещё можно input()'ы вставлять, чтобы программу останавливать на каком-то этапе (иногда надо). Так вот, вот это всё в дебаггере делается моментально, тогда как руками делаешь всё то же самое, только нужно тратить много времени. Короче, делаешь ты меньше за час, чем мог бы делать.
Продолжаю поиски через принты построчно…
Почему сегфолт происходит: обычно причина либо в том, что памяти не хватает, либо в том, что идёт обращение к несуществующему элементу. Если ты неправильно что-то подключил в Qt, то оно будет выдавать тебе такой сегфолт или что-нибудь наподобие (непонятное). Там просто при разрушении виджетов происходят ещё неявные разрушения подвиджетов. И если они неправильно подключены были при создании или там удалены в процессе, то Qt об этом не узнаёт, а продолжает пытаться с ними что-то делать.
py.user.nextДебаггер, конечно, вещь. Но, если до сегфолта тот же notify() вызывается десятки-сотни тысяч раз, то сколько раз должен нажать на клавишу для перехода к следующему брейкпоинту, даже если в коде стоит лишь одна точка останова?
Сначала через принты, но потом дойдёшь до дебаггера. Хотя разницы нет, просто дебаггер быстрее и там много всего автоматизировано (поиск функции, постановка и снятие брейкпоинтов, быстрый проход до брейкпоинта). Ещё можно input()'ы вставлять, чтобы программу останавливать на каком-то этапе (иногда надо). Так вот, вот это всё в дебаггере делается моментально, тогда как руками делаешь всё то же самое, только нужно тратить много времени. Короче, делаешь ты меньше за час, чем мог бы делать.
Для принтов как раз не требуется обращение с клавишами. Задача: найти ту функцию, которая предшествовала вызову notify() до сегфолта.
VadyНабираешь “10000 c” и он проходит 10000 раз без остановки, а потом останавливается. Плюс ещё брейкпоинты можно сохранять в файл и загружать обратно, когда ты снова собрался отлаживать то же самое. А файлы можно сделать разные, для разных случаев, ну и так далее. Сначала тоже так все сидели с принтами, а потом придумали дебаггер. Дебаггер просто автоматизирует это всё - то, что раньше делали руками.
то сколько раз должен нажать на клавишу для перехода к следующему брейкпоинту, даже если в коде стоит лишь одна точка останова?
VadyДа и сегфолт можно отследить. Но если ты дебаггер не освоил, то понятно, что с сегфолтом ты не разберёшься. Там всё посложнее, чем простое использование дебаггера.
Задача: найти ту функцию, которая предшествовала вызову notify() до сегфолта.