О монографии не слышал. Кстати надо печатать и в конструкторе, возможна ABA. Вообще первое что нужно сделать - добиться стабильности краша, идеи/мысли для этого у Вас есть. Если стабильно летит - дальше уже "дело техники" и все такое. Самое мерзкое если появится так раз в месяц - и с приветом, вымотает все кишки 

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

Куплю для себя в коллекцию или можно обменять старые Швейцарские франки CHF ( в том числе 8 серия ! ), старые бумажные английские фунты стерлингов вышедшие из оборота и уже не являющиеся платёжным средством +79997153560 звоните или пишите вацап, интересует любые номиналы.

Вышедшие из обращения немецкие марки, шведские кроны, норвежские кроны, датские кроны и другие банкноты некоторых развитых стран. Просроченные европейские банкноты и другую редкую валюту, которую нельзя сдать в обменник.

Покупаю купюры которые не принимают в банки и уже нельзя сдать обменять в обменные пункты. 

Возможен выезд к Вам оценка, покупка и обмен.Если Вы хотите продать или поменять, то пишите Ваши предложения на WhatsApp и Viber +79997153560

напр так
И при краше сравнить receiver c напечатанным.
Хорошо если так 

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

Нашел вариант, пробижаться по тексту и найти индекс начала и конца слова, и через метод select() с 2 аргументами выделить слово.
Но вот есдинственное что не могу найти, так это как отобразить ту область в тексте где найдено слово.
Как понимаю надо наверное перейти к курсору.
Может кто подсказать, вдруг имели опыт.

Маловато "фактов". Хорошо бы получить останов (или хотя бы краш) в своем коде/фильтре. Посмотреть что за QEvent, здесь вариантов немного. Убедиться что это действительно удаление, печатая в ~QModbusRtuClient адрес экземпляра

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

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

Фрагмент кода не должен приводить к краху по рассматриваемой причине.
Код в деструкторе лишний, так как при конструировании modbusDevice указан родитель this, который и управляет его временем жизни.


Все сигнал слот соединения разрываются и все сообщения для modbusDevice удаляются из очереди обработки при его удалении.
Поэтому ситуации "сокетом формируется сигнал ошибки и отправляется уже удаленному modbusDevice" при корректной реализации быть не может.

Здесь на лицо проблема конкурентного доступа к экземпляру объекта. Обработка сообщений происходит в одном потоке, удаление объекта в другом.
Можно проверить это с помощью определения своего типа производного QModbusRtuClient, например, и вывода и сравнении информации о потоке в деструкторе и обработчиках сигналов.

Вариантов управления временем жизни не так уж и много:

• объект на стеке - удалиться при потере области видимости в том же потоке, где был создан, независимо от потока обработки событий
• член класса - удалиться вместе с экземпляром агрегата, независимо от потока обработки событий
• умный указатель - удалиться вместе удаления умного указателя, независимо от потока обработки событий
• Qt parent-child отношение - удалиться вместе с экземпляром родителя, независимо от потока обработки событий
• new/delete - удалиться в вместе вызова delete, независимо от потока обработки событий
• deleteLater - удалиться в потока обработки событий, независимо от других способов владения (кроме Qt parent-chaild)

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

Удаление, изменение и т.д. конфигурации не должно приводить в краху программы. Решение задачу с помощью "отложенное удаление старой конфигурации ...", лишь усугубит ситуацию, так как проблема никуда не денется, а частота её появления уменьшиться.

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