Russian Qt Forum

В приложении возникла необходимость собственной расширенной обработки GPF ака SIGSEGV и других "низкоуровневых" критических исключений. Приложение управляет аппаратурой, которую при таких исключениях надо корректно выключить. Кроме этого, завершение работы приложения при GPF в модуле управления аппаратурой не обязательно - этот модуль является динамически загруженной библиотекой, и его можно попытаться выгрузить, и загрузить заново. С другими частями приложения он общается только через сигналы. То есть, GPF в нем изолированы, и не влияют на остальные части приложения. Пока не удалось определить точно из-за чего возникает GPF, поскольку это происходит очень редко, и явно связано с входными данными от аппаратуры. При каком-то определенном наборе входных данных что-то происходит неправильно. Имитировать не удается. Поэтому надо отлавливать GPF, еще чтобы разобраться, почему падает. Но GPF возникает в отдельной QThread, которая занимается работой с аппаратурой. И таких QThread может быть несколько...

Вот тут теперь вопрос - если GPF в QThread, как лучше с ним поступить? Первая мысль - в самом начале этого потока сделать try, и ловить catch исключение в этом же потоке. Но так получается пока не очень красиво, из-за особенностей реализации. А try перед стартом потока представляется не корректным - в catch мы вывалимся с неправильным контекстом процесса. Или же такая ситуация предусмотрена где-то в недрах QThread, и всё будет нормально?

Почему бы не анализировать core dump после необработанного падения?

чево???... при чём тут core dump?  :o еще раз - приложение не должно упасть из-за GPF в отдельном модуле, оно должно что-то сделать, и попытаться восстановить работоспособность модуля