Как отследить прерывистый сбой, который происходит только под отладчиком, но не перехватывается им? - PullRequest
Новая
       31

Как отследить прерывистый сбой, который происходит только под отладчиком, но не перехватывается им?

8 голосов
/ 22 августа 2011

У меня странный прерывистый сбой, который происходит только при некоторых обстоятельствах , что мне не удается решить, и я ищу совет SO, как его решить.

Ошибка

В явно случайных точках Windows показывает диалоговое окно «[Приложение] перестало работать». Это APPCRASH в ntdll.dll, код исключения 4000001f, смещение исключения 000a2562. Вот где это становится сложным: это происходит только при запуске приложения под отладчиком. Однако отладчик не перехватывает это исключение, и в тот момент, когда Windows отображает это диалоговое окно, среда IDE не отвечает. Эта ошибка не возникает при нормальной работе, т.е. не в отладчике IDE.

Screenshot of the Windows crash dialog

Я не могу воспроизвести его вне отладчика, поэтому я не могу запустить программу и подключиться, когда она уже потерпела крах. Я не могу приостановить выполнение, когда Windows показывает это диалоговое окно, так как среда не отвечает. Я могу вручную проследить через строки кода, чтобы увидеть, где это происходит. Их несколько, и где это происходит, по-видимому, случайно. Некоторое время это происходило при отображении окна (или новой формы), некоторое время при создании потока.

Редактировать: Я отследил его до IDE: если я сделаю паузу на точке останова и перейду на вкладку Статус потока, программа сразу же вылетит с помощью приведенного выше диалога, даже если теоретически оно приостановлено. В этой ситуации IDE остается отзывчивым. Это действительно странно.

Дополнительная информация

Я только что переместил свою среду разработки на VMWare Fusion . Ошибка также возникает при сборке со старого компьютера (Windows) на моем новом компьютере; это не произошло с тем же файлом EXE на этом старом компьютере. Это заставляет меня задуматься, связано ли это с Fusion или чем-то в моей новой установке.

Я бегу:

  • Windows 7 Pro x64 на WMWare Fusion 3.1.3 на OSX Lion 10.7.1, все полностью обновлено. Fusion работает в режиме «Полный экран» на одном из моих экранов.
  • Коллега, работающий под управлением Windows 7 (не на виртуальной машине), не сталкивается с этой проблемой. Я также не на моем старом компьютере Vista.
  • Embarcadero RAD Studio 2010, полностью обновленный (я надеюсь, что существует около пяти обновлений, и привести их в порядок сложно). У меня установлен DDevExtensions 2.4.1, а также последняя версия IDE Fix Pack: удаление обоих эффект.
  • Приложение написано в основном на C ++, с фрагментами Delphi. Это 32-битный.
  • Мы используем EurekaLog , но исключение также не перехватывается. (Обычно исключение отлавливается сначала отладчиком, а затем EurekaLog.)
  • Запуск отладочной сборки (без EurekaLog, дополнительной отладочной информации и т. Д., Для отладочных DCU, имеющих значение true) также воспроизводит его. Однако опция «Отладка DCU» на странице «Связывание Delphi» в диалоговом окне настроек проекта C ++ Builder, похоже, не дает никакого эффекта - я не могу войти в код VCL и найти строку, которая фактически вызывает ошибку.
  • Codeguard (который обнаруживает ошибки доступа к памяти, двойное освобождение, доступ к освобожденной памяти, переполнение буфера и т. Д.) Ничего не сообщает.

Ответы [ 4 ]

8 голосов
/ 22 августа 2011

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

Лучший из известных мне способов отладки - это загрузить полную версию FastMM и запустить ее с включенными полными параметрами отладки.

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

Другая проблема, с которой я столкнулся в D2010, - это проблема при смешении определений локальных классов (то есть класса внутри класса) с обобщениями. Сгенерированный код в порядке, но отладочные DCU неверны, и при пошаговом выполнении кода отладчик переходит к неправильному файлу и вскоре умирает. У вас, похоже, нет такой же проблемы, но есть некоторые сходства в смерти IDE.

Наконец, я бы посоветовал вам подозревать собственный код, а не VMware. Всегда заманчиво обвинять что-то еще, но, по моему опыту, всякий раз, когда я это делал, это всегда был мой код в конце!

3 голосов
/ 26 июня 2013

Я столкнулся с довольно похожей проблемой.Я также разрабатывал .dll, и когда я установил точку останова где-нибудь в своем коде, Delphi остановился на строке исходного кода, и хост-приложение немедленно завершилось сбоем.

Закрытие «Окна состояния потока»В отладочной раскладке «исправлена» проблема.Я работаю над 64-битной Windows 7 и Delphi XE3.

2 голосов
/ 22 мая 2015

4000001F - это STATUS_WX86_BREAKPOINT

Другими словами, это INT 3, который не был обработан IDE.

Так как он вызывается в NTDLL - я бы предположил, что это указание на памятькоррупция в системной куче.Помните, что некоторый код Windows переключится на версию отладчика при работе в отладчике.Вот почему вы не можете воспроизвести это, когда приложение работает автономно вне отладчика - потому что точка останова не генерируется.

Вы можете попробовать FastMM в режиме полной отладки, но я не думаю, что это поможет вам.Повреждение не происходит в вашей памяти, это происходит в системной памяти.Да, возможно, схема распределения памяти будет изменена - и ваша коррупция покажет себя в вашем коде / памяти ... может быть.Попробуйте использовать распределение сверху вниз, попробуйте использовать SafeMM ...

Другим возможным подходом было бы использование Application Verifier .

См. Также:

1 голос
/ 11 декабря 2013

Проверьте файл Project dsk и убедитесь, что в нем нет ссылки, указывающей на неправильный модуль.Исправление заключается в том, чтобы открыть dsk в редакторе и изменить местоположение файла на правильное местоположение.

...