Russian Qt Forum
Апрель 27, 2024, 12:48 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2   Вниз
  Печать  
Автор Тема: Ошибка "Segmentation fault"  (Прочитано 1236 раз)
sergek
Гипер активный житель
*****
Offline Offline

Сообщений: 870


Мы должны приносить пользу людям.


Просмотр профиля
« : Март 29, 2024, 14:36 »

Коллеги,
пытаюсь отловить фатальную ошибку SIGSEGV "Segmentation fault". Возникает при выполнении одной из операций и довольно стабильно проявляется (но не всегда). Программа - система мониторинга оборудования, довольно сложная, многопоточная, активно используются сигнально-слотовые связи, работа с БД, с железом и т.д. Операция, на которой ломается программа - это обновление конфигурации оборудования, сводится к остановки сервисов опроса, загрузке новой конфигурации, подключения к оборудованию и запуск сервисов. Есть вложенные циклы событий в разных потоках, да и много чего еще.
Я это упоминаю, чтобы вы хоть небольшое представление имели.

Конкретный вопрос я сформулировать не могу, но, может, подскажете, куда мозги повернуть?
При возникновении ошибок стек вызовов (глубина ~25) мне ничего не дает - вызовы идут из библиотечных qeventloop.cpp,  qeventdispatcher.cpp и завершаются на QCoreApplication::notifyInternal2. И ломается на операторе, отмеченном "==>":

Код
C++ (Qt)
bool QCoreApplication::notifyInternal2(QObject *receiver, QEvent *event)
{
   bool selfRequired = QCoreApplicationPrivate::threadRequiresCoreApplication();
   if (!self && selfRequired)
       return false;
 
   // Make it possible for Qt Script to hook into events even
   // though QApplication is subclassed...
   bool result = false;
   void *cbdata[] = { receiver, event, &result };
   if (QInternal::activateCallbacks(QInternal::EventNotifyCallback, cbdata)) {
       return result;
   }
 
   // Qt enforces the rule that events can only be sent to objects in
   // the current thread, so receiver->d_func()->threadData is
   // equivalent to QThreadData::current(), just without the function
   // call overhead.
   QObjectPrivate *d = receiver->d_func();
==> QThreadData *threadData = d->threadData;
   QScopedScopeLevelCounter scopeLevelCounter(threadData);
   if (!selfRequired)
       return doNotify(receiver, event);
   return self->notify(receiver, event);
}

Отлачик дает, вроде, нормальные значения:

Код:
	Локальные переменные		
cbdata @0x1007c500 void*[3]
[0] 0x10d897d0 void*
[1] 0x1007c5a0 void*
[2] 0x1007c51f void*
d 0xabababababababab QObjectPrivate*
event @0x1007c5a0 QTimerEvent
[QEvent] @0x1007c5a0 QEvent
id 28 int
receiver @0x10d897d0 QObject
[vptr] _vptr.QObject
d_ptr 12370169555311111083 QScopedPointer<QObjectData>
staticMetaObject @0x6bbbdfc0 QMetaObject
staticQtMetaObject @0x6bbbe240 QMetaObject
result false bool
scopeLevelCounter <оптимизировано>
selfRequired true bool
Инспектор
Выражения
Возвращаемое значение
Подсказка
doNotify 9892236762171331414 bool (QObject *, QEvent *)
threadData <no such value>


У вас есть мысли, какие возможные причины могут приводить к ошибке на отмеченном операторе?
« Последнее редактирование: Апрель 04, 2024, 13:48 от sergek » Записан

Qt 5.13.0 Qt Creator 5.0.1
Win10, Ubuntu 20.04
Apktyc
Самовар
**
Offline Offline

Сообщений: 132


Просмотр профиля
« Ответ #1 : Март 29, 2024, 14:58 »

Адрес в d 0xabababababababab выглядит максимально подозрительно и, возможно, намекает на переполнение стека.
« Последнее редактирование: Март 29, 2024, 15:01 от Apktyc » Записан
kambala
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4727



Просмотр профиля WWW
« Ответ #2 : Март 29, 2024, 15:33 »

попробуй asan / tsan / valgrind
Записан

Изучением C++ вымощена дорога в Qt.

UTF-8 has been around since 1993 and Unicode 2.0 since 1996; if you have created any 8-bit character content since 1996 in anything other than UTF-8, then I hate you. © Matt Gallagher
sergek
Гипер активный житель
*****
Offline Offline

Сообщений: 870


Мы должны приносить пользу людям.


Просмотр профиля
« Ответ #3 : Март 30, 2024, 11:40 »

Спасибо за советы, коллеги.
Записан

Qt 5.13.0 Qt Creator 5.0.1
Win10, Ubuntu 20.04
ssoft
Программист
*****
Offline Offline

Сообщений: 579


Просмотр профиля
« Ответ #4 : Апрель 01, 2024, 08:37 »

Такое впечатление, что receiver не живой или почти не живой.
Базовый тип QObject выглядит подозрительно.

Нет ли сигнал слот взаимодействия через DirectConnection для объектов, связанных с разными потоками?
Или может сигнал слот взаимодействие через обычный AutoConnection, а потом используется moveToThread()?
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3258


Просмотр профиля
« Ответ #5 : Апрель 02, 2024, 14:50 »

Адрес в d 0xabababababababab выглядит максимально подозрительно

посмотри еще чем остальные треды заняты - надо смотреть не вызываются ли деструкторы чего-то в этот момент (собственно ресивера могут в этот момент удалять)
Записан
sergek
Гипер активный житель
*****
Offline Offline

Сообщений: 870


Мы должны приносить пользу людям.


Просмотр профиля
« Ответ #6 : Апрель 02, 2024, 22:27 »

Такое впечатление, что receiver не живой или почти не живой.
Базовый тип QObject выглядит подозрительно.
На мой взгляд, это вероятная причина. Именно над исключением такой возможности я и работал больше всего. Перед удалением объектов отключал все соединения, очищал мои очереди запросов, закрывал подключения к портам. Это все дает кое-какие результаты, но не 100%.
Такое ощущение, что вызовы сигнал/слот ставятся в очередь, потом я удаляю соединенные объекты (подключения при этом должны автоматически отключиться), и после этого выполняется вызов слота. Интересно, возможно такое? Если да, то это многое объясняет.
Возможно, где-то тут еще порылся deleteLater, но при удалении объектов я его не использую.

Нет ли сигнал слот взаимодействия через DirectConnection для объектов, связанных с разными потоками?
DirectConnection не использую, только AutoConnection и изредка QueuedConnection

Или может сигнал слот взаимодействие через обычный AutoConnection, а потом используется moveToThread()?
А это имеет значение? Если да, то позор мне...  Грустный

посмотри еще чем остальные треды заняты - надо смотреть не вызываются ли деструкторы чего-то в этот момент (собственно ресивера могут в этот момент удалять)
Я тщательно за этим слежу. Конфигурация, которая пересоздается, находится в потоке ядра программы. Остальные потоки сервисов содержат слоты, выполняющиеся по таймерам, и взаимодействуют с ядром. Перед персозданием конфигурации таймеры останавливаются и взаимодействия с ядром не происходит.
Проверял.

В общем, пока у меня рабочая версия проблемы, что где-то я накосячил в межпотоковом взаимодействии. Хотя раз десять переделывал эти процедуры.
Довел до стабильного результата в случае, если у меня вся периферия отвечает нормально, без таймаутов. Если на шине какое-нибудь устройство ломается и растет очередь запросов, во тут пересоздание конфигурации ведет к краху (но не всегда) Почти верный признак того, о чем говорит ssoft. Подмигивающий

Прошу прощения, коллеги, за весьма путанные объяснения.
Записан

Qt 5.13.0 Qt Creator 5.0.1
Win10, Ubuntu 20.04
Igor_S
Новичок

Offline Offline

Сообщений: 9


Просмотр профиля
« Ответ #7 : Апрель 03, 2024, 08:00 »

Да, receiver выглядит калечным. Если он убит "хвостом", то куча испорчена. И может за это зацепиться
Цитировать
  // Qt enforces the rule that events can only be sent to objects in
   // the current thread, so receiver->d_func()->threadData is
    // equivalent to QThreadData::current(), just without the function
    // call overhead.
Навесить хвильтр где сравнить receiver->d_func()->threadData и QThreadData::current(), получить там останов
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 579


Просмотр профиля
« Ответ #8 : Апрель 03, 2024, 14:56 »

Или может сигнал слот взаимодействие через обычный AutoConnection, а потом используется moveToThread()?
А это имеет значение? Если да, то позор мне...  Грустный

Такие ошибки чаще всего связаны именно с этим. Значение имеет огромное.

Когда осуществляется connect по AutoConnection выбирается способ соединения в соответствии с потоками обработки событий объектов.
Если потоки одинаковые, то AutoConnection == DirectConnection.

После moveToThread объект меняет поток обработки событий, а соединения остаются связанными через DirectConnection.
События в одном потоке, сигнал слот в другом, отсюда следует UB в случае конкурентного доступа к полям экземпляра объекта.
И программа может упасть не обязательно из-за деструктора, а в любой момент в процессе работы.
А уж если деструктор вызвался, то практически гарантировано упадет (но есть случаи, когда может и не упасть)). UB оно такое).
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 579


Просмотр профиля
« Ответ #9 : Апрель 03, 2024, 15:21 »

И ещё... Если иcпользовался moveToThread, то удалять нужно через deleteLater(), чтобы удаление произошло в правильном потоке.
Записан
sergek
Гипер активный житель
*****
Offline Offline

Сообщений: 870


Мы должны приносить пользу людям.


Просмотр профиля
« Ответ #10 : Апрель 03, 2024, 17:10 »

Да, receiver выглядит калечным. Если он убит "хвостом", то куча испорчена. И может за это зацепиться
Навесить хвильтр где сравнить receiver->d_func()->threadData и QThreadData::current(), получить там останов
Вы, видимо имели в виду QObject::eventFilter? Я плохо разбираю феню кулхацкеров  Подмигивающий, не очень понял, как это реализовать.

И программа может упасть не обязательно из-за деструктора, а в любой момент в процессе работы.
А уж если деструктор вызвался, то практически гарантировано упадет (но есть случаи, когда может и не упасть)). UB оно такое).
Еще раз проверил, для перемещаемых объектов порядок правильный, например:
Код
C++ (Qt)
   // сервис архива
   archiving->moveToThread(&archivingThread);
   QObject::connect(&archivingThread, &QThread::finished, archiving, &CServiceArchives::deleteLater);
   QObject::connect(this, &CServiceManagement::serviceArchiveSig, archiving, &CServiceArchives::serviceRunSlot);
   QObject::connect(archiving, &CServiceBase::stateChangedSig, this, &CServiceManagement::servStateChangedSlot);
   archivingThread.setObjectName("archiving");
   archivingThread.start();
 

И ещё... Если иcпользовался moveToThread, то удалять нужно через deleteLater(), чтобы удаление произошло в правильном потоке.
Для объектов, для которых использовались сигнально-слотовые соединения, сделал deleteLater - результат аналогичный.

Код я еще перетряс. Самое поганое, что эта функция (обновление конфигурации) стала работать стабильнее, но при определенных условиях все же валится (но не всегда  Подмигивающий).
Сделаю паузу, глаз замылился, переключусь на другое. Коллеги, спасибо.

Записан

Qt 5.13.0 Qt Creator 5.0.1
Win10, Ubuntu 20.04
Igor_S
Новичок

Offline Offline

Сообщений: 9


Просмотр профиля
« Ответ #11 : Апрель 04, 2024, 07:18 »

Вы, видимо имели в виду QObject::eventFilter? Я плохо разбираю феню кулхацкеров  Подмигивающий, не очень понял, как это реализовать.
Напр так
Код:
bool MyApp::notify(QObject *object, QEvent *event)
{
  ...
  return QGUIApplication::notify(object, event);
}
И пытаться как-то определить что поле QObjectPrivate * испорчено (ну хотя бы нечетный адрес). Придется подключить приватные хедеры.

С удалением может быть и никак не связано, просто кто-то пишет не туда куда надо, и объект попадает под раздачу. Поэтому первым делом надо проверять кучу (средствами вашей IDE)
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 579


Просмотр профиля
« Ответ #12 : Апрель 04, 2024, 08:21 »

Код
C++ (Qt)
QObject::connect(&archivingThread, &QThread::finished, archiving, &CServiceArchives::deleteLater);
 

Цитировать
If deleteLater() is called after the main event loop has stopped, the object will not be deleted.

Что-то подсказывает мне, что archiving никогда не удалиться), цикл обработки событий уже не работает.
Одна морока с этим moveToThread  В замешательстве

Конечно, хотелось бы увидеть весь проект или тестовый пример, или хотя бы стек вызовов по всем потокам.
Записан
sergek
Гипер активный житель
*****
Offline Offline

Сообщений: 870


Мы должны приносить пользу людям.


Просмотр профиля
« Ответ #13 : Апрель 04, 2024, 11:35 »

И пытаться как-то определить что поле QObjectPrivate * испорчено (ну хотя бы нечетный адрес). Придется подключить приватные хедеры.
Теперь, кажется, понятно - ловить событие от sender`а в receiver`а. Но что мы поймаем, если приемник уже разрушен? В том то и проблема, что мы цепочкой сигнал/слот можем управлять только со стороны объекта, который отправляет событие. А на стороне приемника мы не можем ничего сделать. Если бы соединение сигнал/слот мы бы могли отключать со стороны приемника, проблем бы не возникало.

Что-то подсказывает мне, что archiving никогда не удалится), цикл обработки событий уже не работает.
Удалится. Цикл в main еще работает в то время, как останавливаются потоки. Там у меня работает QtService, а вся программа выполнена в виде процесса.
Не поленился, проверил - деструктор archiving срабатывает (впрочем, я это и раньше проверял, просто убедился еще раз).

Конечно, хотелось бы увидеть весь проект или тестовый пример, или хотя бы стек вызовов по всем потокам.
Увы, сам проект ~50 тыс. строк, сделать минимальный пример - нехилая работа.
Но это уже и не требуется - проблему я локализовал. И она, как сразу мне подсказывали, в том, что "что receiver не живой".
Но пока не решил, что с этим делать.

В двух словах о проблеме, чтобы не было такого: "всем спасибо, все свободны" Улыбающийся.
У меня в составе ядра системы есть программные компоненты, отвечающие за взаимодействие с периферийными устройствами через аппаратные интерфейсы (usb, uart, i2c, ethernet и т.д.). В их задачу входит получение запросов от сервиса опроса или других, его преобразование в соответствии с прикладным протоколом (modbus, can, mqtt и т.д.) в raw-данные, передача в шину и получение ответа устройств. Что-то типа драйверов, я называю их контроллерами интерфейсов. Уверен, вы найдете более правильное название))

Крах программы наблюдается, когда я перед загрузкой новой конфигурации удаляю старые объекты контроллеров, использующих протоколы modbus rtu по протоколу TCP/IP. Это мой компонент (QModbusRtuClient), я сделал его на основе уже имеющихся в составе qtserialbus, исходники я публиковал где-то здесь. Ключевые фрагменты кода (не существенные части я пропускаю, отмечено '...'):

Код
C++ (Qt)
CModbusInterface::CModbusInterface(...) {
...
       //
       modbusDevice = new QModbusRtuClient(this);
...
}
 
CModbusInterface::~CModbusInterface(){
   if (modbusDevice) {
       modbusDevice->deleteLater();
   }
}
 
Объект modbusDevice реализует формирование запросов, передачу в шину, получение ответов и обработку ошибок. Думаю, фрагменты кодов тут не нужны - они есть в документации qt. Главное в том, что в этом объекте есть TCP-сокет, сигналы которого обрабатываются в CModbusInterface.

При удалении старой конфигурации удаляются объекты CModbusInterface. Если на шине все хорошо, все устройства отвечают (время реакции от нескольких мс до нескольких десятков мс), то удаление modbusDevice проходит успешно.
Но если какое-нибудь устройство перестает отвечать, включается механизм  таймаутов и повторов (ретрейнов) - это стандартное поведение компонетов modbus в qt. Т.е. если перед удалением контроллера мой запрос передан в шину, то он в modbusDevice болтается еще как минимум (1+numberOfRetries)*timeout - несколько секунд, после чего сокетом формируется сигнал ошибки и отправляется уже удаленному modbusDevice. И программа валится.

Изменить timeout и numberOfRetries перед удалением не удастся, т.к. они начинают действовать на следующий запрос, и никак не влияют на текущий.
Почему я особо отметил, что используется TCP-сокет: для последовательного порта в библиоеке используется QSerialPort::clear(QSerialPort::AllDirections), что, видимо, обеспечивает при удалении объекта очистку всех буферов и предотвращает формирование сигналов портом. По крайней мере, при работе через последовательные порты у меня программа не валится. Для сокета такой функции нет.

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

Вот теперь могу сказать: спасибо, коллеги, за помощь.
« Последнее редактирование: Апрель 04, 2024, 13:56 от sergek » Записан

Qt 5.13.0 Qt Creator 5.0.1
Win10, Ubuntu 20.04
Igor_S
Новичок

Offline Offline

Сообщений: 9


Просмотр профиля
« Ответ #14 : Апрель 04, 2024, 12:57 »

Для человека "вне (вашего) проекта" информативно это
...после чего сокетом формируется сигнал ошибки и отправляется уже удаленному modbusDevice. И программа валится.
И что, Qt позволяет вот так "отправить сигнал удаленному"? Не должно

Тему закрываю.
Зачем? Кому-то мешает?  Улыбающийся

Одна нормальная тема в год - и ту закрывает  Плачущий
« Последнее редактирование: Апрель 04, 2024, 13:22 от Igor_S » Записан
Страниц: [1] 2   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.186 секунд. Запросов: 23.