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

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

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

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

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

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

Напр так
И пытаться как-то определить что поле QObjectPrivate * испорчено (ну хотя бы нечетный адрес). Придется подключить приватные хедеры.

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

Вы, видимо имели в виду 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 - результат аналогичный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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