Инструменты для отладки, когда отладчик не может доставить вас туда?

Question

У меня довольно сложное (около 200 000 строк кода на C++) приложение, которое решило сбой, хотя оно несколько отличается от нескольких разных систем. Хитрость заключается в том, что он не разбивается или не попадает в отладчик. Он только сбой, когда приложение .EXE запускается независимо (либо отладчик EXE, либо EXE выпуска - оба ведут себя одинаково). Когда он сбой в отладочном EXE, и я заставляю его запускать отладку, стек вызовов скрывается в части вещей Windows/MFC и не отражает какой-либо из моего кода. Возможно, я вижу что-то вроде стека, но на данный момент я просто не уверен. Мой вопрос более общий - речь идет о инструментах и ​​методах.

Я старый программист (C и дни ассемблера) и относительный новичок (пара/несколько лет) для C++ и Visual Studio (2003 для этого проекта).

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

Единственное, о чем я думал, это начать подключать сообщения об отладке/статусе в файл журнала, но это долгий и трудный путь. Был там, сделал это. Любые лучшие предложения? Упускаю ли я некоторые инструменты, которые помогут? Является ли VS 2008 лучше для такого рода вещей?

Спасибо за любые рекомендации. Некоторые очень умные люди здесь (вы знаете, кто вы!).

ура.

Answer 1

Может быть, что у вас есть слишком большой объект на стеке ...

Explainations (из комментариев):

Я дает этот ответ, потому что это единственный случай, я видел, что в Debuger (VS или CodeWarrior) не смогли поймать и увидеть загадочным. Большую часть времени это был большой объект приложения, который был определен в стеке в функции main() и имел членов, не выделенных в куче. Просто вызов new для создания экземпляра объекта фиксировал непонятную проблему. В конце концов, не нужно было получить конкретный инструмент для этого.

Answer 2

lint.

C/C++ Free alternative to Lint?

Answer 3

Я не сделал C++ профессионально на протяжении более 10 лет, но обратно в тот же день я Rational PurifyPlus, который будет хорошим началом, как BoundsChecker (если он еще существует!) Эти продукты находят вне границ доступа, поврежденная память, поврежденный стек и другие проблемы, которые могут оставаться незамеченными до «бум», а затем вы не знаете, где вы находитесь.

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

Если отладчик уменьшает сбой, это может быть по следующим причинам: коррупция

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

Answer 4

Если это повреждение памяти, инструмент отслеживания/диагностики памяти (я использовал для использования BoundsChecker для хорошего эффекта в старые добрые времена C++), вы можете найти и исправить причину в считанные минуты, где любая другая техника coud принимает дни или даже месяцы.

Для других случаев вы предложили другой подход самостоятельно: иногда трудоемкий, но очень эффективный подход к получению «реальной» трассировки стека - это просто использовать printf - значительно недооцененный инструмент отладки, доступный в любой среде. Если у вас есть приблизительная идея, вы можете оседлать область крушения только несколькими сообщениями журнала, чтобы сузить место, а затем добавить больше, когда вы дома в проблемной области. Это может часто выявлять достаточное количество подсказок, которые вы можете изолировать причину аварии в течение нескольких минут, хотя это может показаться большой работой и, возможно, безнадежной причиной, прежде чем вы начнете.

редактировать:

Кроме того, если у вас есть приложение под контролем источника, а затем получить историческую версию с момента, когда вы думаете, что работает, а затем сделать бинарный Чоп между этой датой и «сейчас», чтобы когда проблема начнет возникать. Это может часто сузить ошибку до точной проверки, которая ввела ошибку, и если вам повезет, она укажет вам несколько строк кода. (Если вам не повезло, ошибка не будет столь легко повторяемой, или вы сократите ее до 500-ти файлов, где будет проведен крупный рефакторинг или аналогичный)

Answer 5

Я больше не мог рекомендовать блог от Mark Rusinovich. Абсолютно блестящий парень, у которого вы можете изучить целую кучу методов отладки для окон и многое другое. Особенно попробуйте прочитать некоторые из серии «The Case of»! Удивительные вещи!

Например, взгляните на this случай, который он исследовал, - авария IE. Он показывает, как захватить стек неудачной нити и много интересного. Его основными инструментами являются инструменты отладки окон, а также его инструменты sysinternals!

Достаточно сказано. Пойдите, прочитайте это!

Также я бы рекомендовал книгу: Windows Internals 5. Опять Марк и компания.

Answer 6

Получить комплект инструментов для отладки от MS (http://www.microsoft.com/whdc/devtools/debugging/default.mspx).

Установите adplus для мониторинга режима сбоя (http://www.microsoft.com/whdc/devtools/debugging/default.mspx).

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

Есть довольно много ресурсов вокруг использования WinDbg - хорошая книга по общей Windows, неуправляемый отладки и инструменты в наборах отладки является: http://www.amazon.com/Advanced-Windows-Debugging-ebook/dp/B000XPNUMW

Answer 7

Мой опыт показывает, что когда-нибудь действительно программа, запущенная с помощью отладчика (выпуска или режим отладки) не сбой, как и при запуске самостоятельно.

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

Другой и лучший подход, если авария не всегда происходит, будет иметь возможность создавать мини-накопитель (эквивалент unix coredump) и делать посмертный анализ, есть много инструментов для окон, чтобы сделать это , например, смотрите:

http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx?df=100&forumid=3419&exp=0&select=1114393 (возможно, у кого-то может быть лучшая ссылка, что эта).