Как-то не сразу до меня дошло, что адрес receiver можно взять из стека)) Ну ладно, пригодится на будущее, спасибо.
Хорошо бы где-нибудь почитать про методы отладки в Qt - наработанные приемы, инструменты. Может, есть монография по этой теме?

Как же я смогу это сделать, если ~QModbusRtuClient уже исполнился, а краш происходит через несколько секунд? Проблема-то в том и состоит, что процессы, приводящие к аварийному завершению, связаны (ну, я так думаю;)) с сокетом, а приемник уже уничтожен.
Прямо вот сейчас пришла мысль - можно было бы создать отладочный объект-приемник, который живет все время работы программы, и подключить его к возможным источникам сигналов. Но поздно - я уже все переделываю, не хочется возвращаться к проблеме, которая имеет чисто академический интерес))

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

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

Не вопрос, отменил)) Надо бы тогда тему как-то уточнить, чтобы обсуждение пошло в нужном русле.

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

Удалится. Цикл в 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), что, видимо, обеспечивает при удалении объекта очистку всех буферов и предотвращает формирование сигналов портом. По крайней мере, при работе через последовательные порты у меня программа не валится. Для сокета такой функции нет.

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

Вот теперь могу сказать: спасибо, коллеги, за помощь.

Вы, видимо имели в виду QObject::eventFilter? Я плохо разбираю феню кулхацкеров  , не очень понял, как это реализовать.

Еще раз проверил, для перемещаемых объектов порядок правильный, например:

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();
 

Для объектов, для которых использовались сигнально-слотовые соединения, сделал deleteLater - результат аналогичный.

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

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

DirectConnection не использую, только AutoConnection и изредка QueuedConnection

А это имеет значение? Если да, то позор мне... 

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

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

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

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

Коллеги,
пытаюсь отловить фатальную ошибку 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);
}

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



У вас есть мысли, какие возможные причины могут приводить к ошибке на отмеченном операторе?

А в конце - точка с запятой

К сожалению, это не то Это Роспатент, свидетельство о собственности.
А в Росреестре первая запись датирована 29.01.2016.

Коллеги,
прошло много времени, появиличь ли прецеденты регистрации программ на Qt в росреестре?

Видимо, это застарелая проблема (QTBUG-32987): https://stackoverflow.com/questions/37964891/qprinter-margin-does-not-work-as-expected.
Предлагается бороться с отступом в QTextDocument путем установки размера страницы. Я попробовал и QPageLayout::setMargins, и

C++ (Qt)
docum->setPageSize(QSizeF(printer->pageLayout().pageSize().size(QPageSize::Point))),

но ничего хорошего не получил. Правда, setPageSize на отступы все же как-то влияет, но не так, как хочется.
Попробуйте поискать в этом направлении.

QPrinter::setFullPage не помогает?

У меня есть функция построения 3-хмерных графиков. Правда, написана лет сто назад и для BCpp. Там есть все нужные преобразования, повороты. Если появится желание самому разбираться и перевести на Qt, отправлю в личку. Но с условием, что функцию для Qt мне предоставите.
Что она может, в картинках к этому сообщению.