PDB не показывает точный номер строки для сбоя версии выпуска, но показывает точный номер строки в случае отладочной версии двоичного файла
Я создал приложение для Windows с параметром / DEBUG, чтобы можно было анализировать аварийные дампы, генерируемые при сбое моего приложения. Используя WinDBG (! Analysis -v), я могу видеть только некоторые следы стека, которые не являются точными. Однако, когда я создаю отладочную сборку и мое приложение вылетает, WinDBG сообщает мне точный номер строки, в которой произошел сбой.
Я заранее прошу прощения за своего рода абстрактное обобщение моей проблемы, но я ищу разные взгляды на это и то, как разработчики по всему миру выпускают сборку своих приложений C ++, чтобы можно было проанализировать дамп, соответствующий любому сбою в приложении, чтобы получить точную линию количество аварий
Решение
Я ищу разные взгляды на это и как разработчики вокруг
мир выпускает сборку своих приложений на C ++, чтобы
Соответствующий любой сбой в приложении может быть проанализирован, чтобы получить точный
номер строки аварии
Добро пожаловать в мир посмертной отладки. Ваша проблема типична для оптимизированных приложений для сборки релизов, поэтому вам необходимо использовать все доступные инструменты. В большинстве случаев фактический номер строки будет недоступен. У меня есть несколько предложений.
Не полагайтесь исключительно на WinDbg. Я использую и Windbg, и Visual Studio для анализа аварийных дампов. Я обнаружил, что, используя оба, я получаю более полную картину потенциальной проблемы. Вы также можете посмотреть на использование DebugDiag в качестве дополнительного инструмента для анализа аварийных дампов.
Чтобы помочь точно определить причину сбоя, я добавил дополнительный файл в нашу отчетность. В дополнение к файлу дампа, я также собираю файл журнала, который детализирует контекст того, что пользователь делал во время сбоя. Это не идеально, но помогает узнать, какие типы функций были выполнены и как они были введены. Отчет можно настроить так, чтобы он содержал любую полезную информацию.
Наконец, вы можете установить свой собственный фильтр необработанных исключений собрать любую дополнительную информацию, которая может помочь устранить причину аварии.
Другие решения
Строим правильные символы
Существует несколько типов символов (отсортированных по имеющейся информации):
- нет символов
- экспортные символы
- публичные символы
- частные символы
Отладочная сборка обычно создает закрытые символы с большей частью информации, поэтому информация является достаточно точной. Для сборки выпуска долгое время настройка по умолчанию заключалась в том, чтобы вообще не генерировать символы.
Поэтому, пожалуйста, проверьте, правильно ли вы создали символы.
Проверка символов
Пожалуйста, проверьте, есть ли в ваших символах личная информация. С WinDbg приходит SymChk, Используйте это так:
Symchk /if <exe> /s <pdbdir> /av /od /pf
Важная вещь /pf, Это проверит, если личная информация включена.
Вы также можете проверить это в WinDbg. Сначала убедитесь, что соответствующий модуль (exe) загружен, затем проверьте статус символа:
0:003> ld myExe
Symbols loaded for myExe
0:003> lm m myExe
start end module name
002d0000 002d8000 myExe C (private pdb symbols) E:\...\myExe.pdb
Если WinDbg говорит «частные символы pdb», это должно быть хорошо.
Повреждение памяти
Если стек неправильный, возможно, переполнение или недополнение стека или другое повреждение памяти. Попробуйте включить некоторые GFlags (инструмент поставляется с WinDbg), чтобы приблизиться к реальной проблеме.
GFlags может включить некоторые проверки во время выполнения на предмет повреждения памяти и аварийного сбоя ранее, так что стека вызовов, вероятно, находится в вашем коде, а не в чужом коде.
Лично я никогда не видел некорректные файлы дампа. Это просто копия памяти во время сбоя. Если содержание не соответствовало тому, что я ожидал, всегда была причина, по которой память отличалась, например, утечка памяти.
оптимизация
Наконец, если вы все сделали правильно и по-прежнему видите неправильный результат, это, вероятно, вызвано оптимизацией. В процессе оптимизации операторы на уровне ассемблера могут быть переупорядочены или даже удалены, методы могут быть встроены и т. Д. Таким образом, в конечном итоге это не имеет отношения 1: 1 к вашему коду (в терминах строк кода).
detector