Отчет о сбоях для приложений MinGW - PullRequest
Новая
       3

Отчет о сбоях для приложений MinGW

23 голосов
/ 08 марта 2011

У меня есть приложение c ++, скомпилированное с MinGW, для которого я получаю жалобы от сбоев от клиентов. Поэтому, помимо тщательного входа в части, которые могут быть сбойными (перед выпуском новой версии), я искал репортер аварий, который поможет мне найти трассировку стека и любую другую полезную информацию отладки при возникновении ошибки.

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

Существуют ли какие-либо инструменты Windows, которые могут мне помочь? Приложение работает в основном на машинах с Windows XP.

Для моих целей достаточно иметь возможность записывать информацию в файл. Тогда я могу попросить моего клиента отправить мне информацию по почте.

Я просматривал google-breakpad и SetUnhandledExceptionFilter , но я до сих пор не знаю, будут ли они полезны в любом случае. Другие утилиты отчетов о сбоях, такие как crashrpt , предназначены для Visual C ++, поэтому, думаю, пробовать их с MinGW не имеет большого смысла.

РЕДАКТИРОВАТЬ: некоторые полезные ссылки по теме

1 Ответ

15 голосов
/ 08 марта 2011

На самом деле проблема не в том, чтобы заставить работать отчеты о сбоях.Это довольно тривиально с библиотечными функциями DbgHelp и наиболее заметно там MiniDumpWriteDump.Помните, однако, что нужно распространять библиотеку DbgHelp на старых системах и соблюдать требования к версиям для функций, которые вы собираетесь вызывать - более новые версии Windows поставляются по крайней мере с некоторыми версиями этой библиотеки.

Ваша проблема с использованиемкомпилятор не-MS (проблема также существует с Embarcadero, ранее Borland, продуктами, например, или Watcom) в том, что созданные символы отладки не имеют смысла для библиотеки DbgHelp, которая стандартное средство для отладки в Windows.Формат PDB в значительной степени недокументирован (для некоторых подсказок ищите термины: Sven Schreiber PDB ), а библиотеки, используемые для создания , они не являются «публичными» в том же смысле, что и DbgHelpбиблиотека - последняя может использоваться только для чтения / анализа созданных отладочных символов.Они являются частью продуктов Visual Studio и обычно называются как mspdbXY.dll (где XY - десятичные цифры).

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

  1. Используйте отладчик, который понимает ваш конкретный формат отладки (GDB для DWARF в MinGW, IIRC)
  2. Используйте отладчик, который понимает несколькоформаты (IDA приходит на ум и имеет и другие преимущества;))
  3. Напишите расширение для чего-то вроде WinDbg, чтобы понять смысл ваших символов отладки (DWARF) или, в более общем смысле, .map файлов (яПомните, что такие расширения были написаны несколько лет назад для файлов Borland .map)
  4. Изучите язык ассемблера и используйте доступные инструменты (WinDbg или, в более общем случае, библиотеку DbgHelp) без символов (вероятно,слишком крутая кривая обучения, если вы ее еще не знаете)

В качестве расширения до 4 вы также можете позволить GCC создавать файлы .S (сборка) во время компиляции для перекрестной ссылки на исходный код и сбойdump при работе без поддержки символов.

Учитывая, что я предпочитаю GDB на unixoid платформах, но WinDbg и другие отладочныеПо поводу Windows, я не могу точно сказать, есть ли поддержка фактического формата аварийного дампа (созданного с помощью MiniDumpWriteDump) в GDB в Windows, поэтому я не уверен, какой формат может ожидать GDB в этом случае.

Кстати: если вы используете Windows XP или выше и можете полагаться на этот факт, используйте AddVectoredExceptionHandler вместо SetUnhandledExceptionFilter для подготовки записи аварийного дампа.

...