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

Question

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

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

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

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

Answer 1

Вы можете запускать свое программное обеспечение с включенными глобальными флагами (см. Инструменты отладки для Windows). Это очень часто поможет решить проблему.

Answer 2

Попробуйте использовать _CrtCheckMemory () , чтобы увидеть, в каком состоянии находится выделенная память. Если все идет хорошо, _CrtCheckMemory возвращает TRUE , иначе FALSE .

Answer 3

Нечто подобное случилось со мной однажды с GCC. Это оказалось слишком агрессивной оптимизацией, которая была включена только при создании финальной версии, а не в процессе разработки.

Честно говоря, это была моя вина, а не gcc, поскольку я не заметил, что мой код полагается на тот факт, что эта конкретная оптимизация не была бы выполнена.

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

Answer 4

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

Один из способов хотя бы сузить проблему - это использовать MessageBox () для отображения быстрых операторов, указывающих, к какой части программы относится ваш код («Starting Foo ()», «Starting Foo2 ()»); начните помещать их в верхнюю часть функций в той области кода, которую вы подозреваете (что вы делали в тот момент, когда он падал?). Когда вы можете сказать, какую функцию, измените окна сообщений на блоки кода или даже отдельные строки внутри этой функции, пока не сузите ее до нескольких строк. Затем вы можете начать распечатывать значения переменных, чтобы увидеть, в каком они состоянии в момент сбоя.

Answer 5

Заставьте вашу программу генерировать мини-дамп при возникновении исключения, затем откройте его в отладчике (например, в WinDbg). Ключевые функции для просмотра: MiniDumpWriteDump, SetUnhandledExceptionFilter

Answer 6

Вот у меня был случай, который кто-то может счесть поучительным. Сбой только при выпуске в Qt Creator, но не при отладке. Я использовал файлы .ini (поскольку я предпочитаю приложения, которые можно копировать на другие диски, а не те, которые теряют свои настройки в случае повреждения реестра). Это относится ко всем приложениям, которые хранят свои настройки в дереве каталогов приложений. Если сборки отладки и выпуска находятся в разных каталогах, у вас также может быть настройка, отличающаяся между ними. У меня было предпочтение, проверенное в одном, которое не было проверено в другом. Это оказалось источником моего крушения. Хорошо, что я нашел это.

Мне неприятно это говорить, но я только диагностировал сбой в MS Visual Studio Community Edition; после установки VS позволяю моему приложению аварийно завершить работу в Qt Creator и выбрать его открытие в Visual Studio отладчике. Хотя в моем приложении Qt не было информации о символах, оказалось, что в библиотеках Qt их было немного. Это привело меня к оскорбительной линии; так как я мог видеть, какой метод вызывается. (Тем не менее, я думаю, что Qt - это удобный, мощный и кроссплатформенный каркас LGPL.)

Answer 7

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