Короче вот что накопал:
Сигнал 17 - это в Linux SIGCHLD - сигнал информирующий родительский процесс о том, что дочерний процесс завершился или его исполнение было прервано.
В штатной ситуации этот сигнал должен игнорироваться.
Более того именно с этим сигналом работает waitpid() используемый в go-шном process.wait(). Он по сути просто блокирует свое исполнение и возобновляет его по получению SIGCHLD от процесса PID которого в функцию передали параметром.
Что по факту имеем:
1. без goqt все работает правильно, т.е. дефолтный обработчик SIGCHLD отрабатывает как надо и process.wait() работает с SIGCHLD как положено.
2. goqt (насколько я понимаю) устанавливает (в С-шном коде) свой набор обработчиков сигналов для текущей задачи (есть такой механизм с альтернативным стеком обработчиков) и вот в этом стеке нет обработчика для SIGCHLD судя по сообщению:
signal 17 received but handler not on signal stack
fatal error: non-Go code set up signal handler without SA_ONSTACK flagSIGCHLD обычно не обрабатывается сразу, по сути это даже не сигнал, а сообщение: когда приходи SIGCHLD от дочернего процесса в родительском он просто вешается в очередь. И вот как раз при обработке process.wait() (в waitpid()) SIGCHLD от дочернего процесса и высвобождается через syscall. В штатной ситуации waitpid() как раз и получает SIGCHLD через обработчик, но порушенный из goqt обработчик пробрасывает SIGCHLD мимо waitpid(). Ну, а дальше необработанный сигнал штатно валит всю программу.
---------
Ну в итоге: что происходит - понятно, как лечить - пока нет.
Пользователь добавил сообщение 18 Января 2018, 18:31:11:
Короче накопол воркараунд.... точнее сказать костыль
Костыль заключается в том что-бы самому впихнуть этот чертов флаг SA_ONSTACK в обработчик SIGCHLD после всех этих Qt-шных инициализаций.
Так и не смог найти/понять: кто там в Qt или в библиотеке goqt перефигачивает обработчики сигналов без этого флага, но GO без этого флага падает, потому что они для нормальных задач выделяют довольно маленький стек в котором обработать сигнал - не реально (сам сигнал - довольно объемная структура). Для решения такой проблемы и служит флаг SA_ONSTACK - он говорит что обработчик сигнала должен пользоваться специальным стеком (не совсем понял: его заранее выделяют или обработчик как-то сам его выделяет или системный стек используется, но не суть).
Так вот, когда Go получает этот сигнал и у него не стоит флаг SA_ONSTACK, то go просто падает, ибо знает, что обработка сигнала в стандартном стеке приведет к еще более неприятному крашу.
Я накопал сишный код, в котором с этим флагом игрались
ребята которые с этой проблемой столкнулись еще 2014 году и перелопатил его в простую выставлялку флага существующему обработчику. Засунул вызов этого кода сразу за инициализацией библиотеки - и о чудо - все взлетело.
Так что Qt версия (хоть и на костылях) но похоже встает на ноги
Zirrald, скачайте обновы с гита, там я скриптами оформил сборку и установку. Попробуйте запустить в кедах. Если заработает то сделайте мне красивых скриншотов для вики (у меня на крыске qt выглядит очень уродливо).
Пользователь добавил сообщение 18 Января 2018, 19:19:21:
Вобщем виновник - все-таки Qt.
Они там свой обработчик вешают, оригинальный вызывается каскадно.... но вот пока они там все это мудрят - все флаги теряются - нагуглил кучу багрепортов на тему сброса флагов. Go просто наступил на грабли, которые уже истоптали разработчики на Qt.
... пишут вроде как выпилили из Qt5 тот компонент, который так хулиганил, но не факт что этот кривой функционал не перенесли в другие места.
Тема: Плагины/индикаторы для индикации статуса синхронизации с Yandex-disk (Прочитано 935339 раз)
