Программа, которую я поддерживаю, аварийно завершает работу с SIGSEGV, но я не могу из файла .dmp
Согласно названию, я не могу найти файлы дампа, когда эта программа, которую я поддерживаю, падает.
В журналах приложения явно упоминается исключение SIGSEGV, но я искал весь жесткий диск, и нигде не было найдено ни одного файла .dmp.
Разработчики программы видели подобные проблемы в других местах, но до сих пор не смогли объяснить, почему это происходит — и мы немного застряли на данный момент.
Последний раздел в журналах приложения читается как:
Received signal SIGSEGV, segmentation violation.
OurApplication::sigHandler 11.
Removing signal handlers.
OurApplication::signalCatched.
OurApplication::sigHandler: exiting application.
Removing signal handlers.
Мое ограниченное понимание этого заключается в том, что обработчик сигналов нашего приложения может «нейтрализовать» возникшее исключение SIGSEGV. И, следовательно, дамп ядра не генерируется … Я высказал эту идею разработчикам, но они никогда не исследовали, может ли это быть причиной. Теория, которую они выдвинули в счетчике, заключалась в том, что, по их мнению, причина, по которой дамп не генерируется, заключается в том, что программа может аварийно завершить работу дважды, очень близко друг к другу.
Итак, у меня есть следующие вопросы:
- Есть ли какие-либо параметры Windows7, которые управляют созданием файла .dmp?
- Существуют ли какие-либо требования / флаги, которые необходимо скомпилировать в программу, чтобы она (или окна) создавала файл дампа ядра в случае сбоя?
- Я на 99% уверен, что именно Windows должна отвечать за создание файла ядра, так как сама программа была бы неработоспособной или прерванной в случае сбоя, правильно?
- Есть ли какие-либо другие вещи, о которых я должен знать, или проверять, или «доказательства», которые я могу собрать и затем показать нашим разработчикам?
Спасибо заранее
Решение
Есть ли какие-либо параметры Windows7, которые управляют созданием файла .dmp?
Существуют параметры, которые управляют созданием аварийного дампа: см. MSDN на Сбор дампов пользовательского режима.
Существуют ли какие-либо требования / флаги, которые необходимо скомпилировать в программу, чтобы она (или окна) создавала файл дампа ядра в случае сбоя?
Вам не нужно ничего компилировать, чтобы предыдущий ответ работал. Тем не менее, программа должна завершиться из-за необработанного исключения, что означает, что вы должны позволить пузырю исключения и не обрабатываться обработчиком необработанного исключения.
Я на 99% уверен, что именно Windows должна быть ответственна за создание файла ядра, так как сама программа была бы неработоспособной или прерванной после сбоя, правильно?
Как указывалось выше, Windows может справиться с этим, и это хорошая идея, чтобы Windows справилась с падением. Представьте, что ваша программа не работает из-за утечки памяти. Некоторая память была перезаписана. В этом случае ваш необработанный обработчик исключений может быть уничтожен. Однако Windows по-прежнему имеет полный контроль над процессом, может приостановить его и создать дамп извне (а не изнутри).
Есть ли какие-либо другие вещи, о которых я должен знать, или проверять, или «доказательства», которые я могу собрать и затем показать нашим разработчикам?
Что ж, предложите разрешить Windows создавать дамп по указанным выше причинам. Тогда им также не нужно реализовывать настройки конфигурации (вы не хотите, чтобы файл аварийного дампа создавался всегда, не так ли?). Вам не нужно реализовывать ограничивающее число для файлов. Вам не нужно реализовывать проверку дискового пространства и т. Д.
И вы можете предложить прочитать Windows Internals 6 книг.
Другие решения
Подумайте о создании собственного файла минидампа программно. Должно быть много кода, показывающего, как это сделать. Вы можете попробовать здесь:
https://stackoverflow.com/search?q=minidump
Таким образом, вы не полагаетесь на Dr. Watson или любые другие настройки для создания файла дампа. Вместо этого вы будете вызывать функции в DBGHELP.DLL для создания файла дампа.
detector