Программа вылетает только при выпуске сборки - как отлаживать?

Question

У меня здесь проблема типа «Шредингерский кот» - моя программа (на самом деле набор тестов для моей программы, но, тем не менее, программы) аварийно завершает свою работу, но только при сборке в режиме выпуска и только при запуске из командная строка. С помощью отладки пещерного человека (т. Е. Неприятных сообщений printf () повсюду) я определил метод тестирования, в котором происходит сбой кода, хотя, к сожалению, в некоторых деструкторах, по-видимому, происходит сбой, так как последние сообщения трассировки, которые я вижу другие деструкторы, которые выполняются чисто.

Когда я пытаюсь запустить эту программу внутри Visual Studio, она не падает. То же самое происходит при запуске из WinDbg.exe. Сбой происходит только при запуске из командной строки. Это происходит в Windows Vista, кстати, и, к сожалению, сейчас у меня нет доступа к машине с XP для тестирования.

Было бы здорово, если бы я мог заставить Windows распечатать трассировку стека, или что-то , кроме простого завершения программы, как если бы она вышла полностью. У кого-нибудь есть какие-либо советы относительно того, как я мог бы получить здесь более значимую информацию и, надеюсь, исправить эту ошибку?

Редактировать: Проблема действительно была вызвана массивом вне пределов , который я опишу больше в этом посте . Спасибо всем за помощь в поиске этой проблемы!

Answer 1

Иногда это происходит из-за того, что вы завершили важную операцию в макросе "assert". Как вы, возможно, знаете, «assert» вычисляет выражения только в режиме отладки.

Answer 2

Отличный способ отладки такой ошибки - включить оптимизацию для отладочной сборки.

Answer 3

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

Например:

char a[8];
memset(&a[0], 0, 16);

: /*use array a doing some thing */

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

Но в выпуске это может произойти сбой.

Для меня порыться там, где память вышла за пределы, слишком утомительно.

Используйте некоторые инструменты, такие как Visual Leak Detector (windows) или valgrind (linux) - более разумный выбор.

Answer 4

Vista SP1 на самом деле имеет очень хороший генератор аварийных дампов, встроенный в систему. К сожалению, он не включен по умолчанию!

См. Эту статью: http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx

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

Answer 5

Что касается проблем с получением диагностической информации, пытались ли вы использовать adplus.vbs в качестве альтернативы WinDbg.exe? Чтобы присоединиться к запущенному процессу, используйте

adplus.vbs -crash -p <process_id>

Или запустить приложение в случае быстрого сбоя:

adplus.vbs -crash -sc your_app.exe

Полную информацию о adplus.vbs можно найти по адресу: http://support.microsoft.com/kb/286350

Answer 6

Ntdll.dll с прикрепленным отладчиком

Одно небольшое отличие между запуском программы из IDE или WinDbg и запуском ее из командной строки / рабочего стола заключается в том, что при запуске с подключенным отладчиком (т. Е. IDE или WinDbg) ntdll.dll использует другую реализацию кучи, которая выполняет небольшая проверка на распределение / освобождение памяти.

Вы можете прочитать соответствующую информацию в неожиданной точке останова пользователя в ntdll.dll . Одним из инструментов, который может помочь вам определить проблему, является PageHeap.exe .

Анализ сбоев

Вы не написали, что за «сбой» вы испытываете. После сбоя программы и предложения отправить информацию об ошибке в Microsoft вы сможете щелкнуть техническую информацию и проверить хотя бы код исключения, а с некоторыми усилиями вы даже сможете выполнить посмертный анализ (см. Heisenbug: на некоторых компьютерах происходит сбой программы WinApi) для получения инструкций)

Answer 7

Я видел много правильных ответов. Однако, никто не помог мне. В моем случае было неверное использование инструкций SSE с невыровненной памятью . Взгляните на свою математическую библиотеку (если вы ее используете) и попробуйте отключить поддержку SIMD, перекомпилировать и воспроизвести сбой.

Пример:

Проект включает mathfu и использует классы с вектором STL: std :: vector . Такое использование, вероятно, вызовет сбой во время создания элемента mathfu :: vec2 , поскольку распределитель STL по умолчанию не гарантирует требуемого 16-байтового выравнивания. В этом случае, чтобы доказать эту идею, можно определить #define MATHFU_COMPILE_WITHOUT_SIMD_SUPPORT 1 перед каждым включением mathfu , перекомпилировать в конфигурации Release и проверить еще раз.

Конфигурации Debug и RelWithDebInfo хорошо работали для моего проекта, но не Release . Причина такого поведения, вероятно, заключается в том, что отладчик обрабатывает запросы на выделение / освобождение и выполняет некоторую учетную запись в памяти для проверки и подтверждения доступа к памяти.

Я столкнулся с ситуацией в средах Visual Studio 2015 и 2017.

Answer 8

У меня была эта ошибка, и против сбоя даже при попытке! Очистить! мой проект. Поэтому я удалил файлы obj вручную из каталога Release, и после этого он просто отлично сработал.

Answer 9

Я нашел эту эту статью полезной для вашего сценария. ISTR опции компилятора были немного устаревшими. Просмотрите параметры проекта Visual Studio, чтобы узнать, как создавать файлы pdb для сборки выпуска и т. Д.

Answer 10

Подозрительно, что это произойдет вне отладчика, а не внутри; работа в отладчике обычно не меняет поведение приложения. Я бы проверил различия в среде между консолью и IDE. Также очевидно, что компилируем релиз без оптимизаций и с отладочной информацией и проверяем, влияет ли это на поведение. Наконец, ознакомьтесь с инструментами посмертной отладки, предложенными здесь другими людьми, обычно вы можете получить от них некоторую подсказку.