Windbg: когда у нас не воспроизводится. Александр Головач ➠ CoreHard Autumn 2019
Download as PPTX, PDF0 likes208 views
Документ содержит подробное руководство по отладке программного обеспечения, фокусируясь на сложностях, таких как воспроизведение дефектов, утечки памяти и взаимоблокировки потоков. Описываются инструменты, такие как утилиты для анализа дампов памяти и отладчики, а также рекомендуемые процедуры для устранения ошибок. Кроме того, рассматриваются стратегии автоматизации анализа дампов для повышения эффективности работы разработчиков.
![Windbg. Pецепт
19
● Запустить программу под отладчиком
● Поставить точку останова в контрольной точке [1]
● После остановки программы на точке останова выполнить команду
!htrace -enable, продолжить выполнение
● Поставить точку останова в контрольной точке [2]
● После остановки программы на точке останова выполнить команду
!htrace –diff.
При отладке в среде заказчика собрать дамп процесса (.dump /ma file.dmp)
и выполнить команду !htrace во время анализа на стороне
разработчика.](https://image.slidesharecdn.com/when-it-doesnt-get-reproducedcorehard2019light-191210125827/85/Windbg-CoreHard-Autumn-2019-19-320.jpg)
![Windows error reporting
39
Конфигурация создания дампов памяти при аварийном завершении
находится: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows
Windows Error ReportingLocalDumps [ImageName.exe]
DumpFolder Путь к каталогу, в котором будут
сохраняться дампы
REG_EXPAND_SZ
DumpCount Максимальное количество дампов. REG_DWORD
DumpType Тип дампа памяти:
• 0: Custom dump
• 1: Mini dump
• 2: Full dump
REG_DWORD](https://image.slidesharecdn.com/when-it-doesnt-get-reproducedcorehard2019light-191210125827/85/Windbg-CoreHard-Autumn-2019-38-320.jpg)
Windbg: когда у нас не воспроизводится. Александр Головач ➠ CoreHard Autumn 2019
- 1. Когда у нас не воспроизводится Александр Головач + + + + + + +
- 2. О себе Александр Головач Системный программист в Checkpoint Software Technologies Ltd.
- 3. Почему отладка сложна На практике встречаются ситуации, когда: ● Воспроизведение дефекта непредсказуемо ● Дефект проявляется в специфичном окружении, доступ к которому может быть ограничен ● Для воспроизведения дефекта необходимо время ● Для воспроизведения дефекта необходима определенная последовательность событий ● Процесс отладки ведет к нарушению работы ПО, что порой крайне не желательно 3
- 4. Прежде чем мы начнем 4
- 5. Адресное пространство процесса 5 Пространство ядра (общее для всех процессов, недоступно из пользовательского кода) Пространство пользователя (у каждого процесса свое изолированное) USER MODE KERNEL MODE
- 6. Адресное пространство процесса - UM 6 DLLs Heap (at least one) Executable image Stack (per each thread) Thread environment block (TEB) – per thread Process environment block (PEB)
- 7. Дамп памяти процесса 7 HEADER Context info+ info from OS .DMP
- 8. Дамп памяти процесса 8 HEADER Context info+ info from OS Где в дампе памяти находится . . . : ● Информация о модулях, командной строке, переменных окружения - PEB ● Глобальные и статические переменные – секция данных модуля ● Локальные переменные – стек ● Динамические данные – куча. Адреса ищи в глобальных или локальных переменных (см. выше) ● Какой именно код выполнялся в потоке – регистр EIP ● Последовательность вызовов функций – адреса возврата на стеке .DMP
- 9. Как собрать дамп ? 9 ● Используйте Procdump ! ● Task manager ● Process Explorer ● Отладчик
- 10. Отладочные символы 10 ● Отладочные символы (debug symbols) – информация о взаимном соответствии исходного кода и исполняемого модуля. ● Генерируются компоновщиком. ● Различают публичные и приватные отладочные символы публичные символы не содержат информацию о типах, номерах строк, локальных переменных и параметрах функций ● Отладочные символы для Microsoft доступны здесь: https://msdl.microsoft.com/download/symbols
- 11. Утечка дескрипторов на объекты ядра 11
- 12. Утечка дескрипторов на объекты ядра 12 ● Дескриптор (HANDLE) – идентификатор объекта ядра ● Незакрытый дескриптор приводит к тому, что количество ссылок на объект ядра не станет равным нулю. ● Теряя дескрипторы на объекты ядра, процесс влияет на другие процессы и систему в целом Примеры объектов ядра: Process, Thread, File, GDI objects (windows, brushes, palettes), ……
- 13. Предварительный анализ 13 ● Начальный анализ рекомендуется провести с использованием утилит ○ Handle ○ Process monitor ○ Process explorer ● Process explorer может показать дескрипторы процесса, их тип и имена соответсвующих объектов ядра (если применимо) ● Process monitor показывает активность процесса. Открытие ключей реестра и файлов журналируется, для операций доступен стек вызова.
- 16. HANDLE 16
- 17. Application verifier. Pецепт 17 На машине с воспроизведением: ● Добавить свое приложение в список верифицируемых ● В списке Tests указать Basic->Handles ● Запустить приложение, воспроизвести ошибку ● Собрать дамп На машине разработчика: ● Открыть дамп памяти ● Использовать команды !htrace, !handle в отладчике WinDbg
- 19. Windbg. Pецепт 19 ● Запустить программу под отладчиком ● Поставить точку останова в контрольной точке [1] ● После остановки программы на точке останова выполнить команду !htrace -enable, продолжить выполнение ● Поставить точку останова в контрольной точке [2] ● После остановки программы на точке останова выполнить команду !htrace –diff. При отладке в среде заказчика собрать дамп процесса (.dump /ma file.dmp) и выполнить команду !htrace во время анализа на стороне разработчика.
- 20. Пример 20
- 21. Подведем итог 21 ● Предварительный анализ выполняем утилитами Sysinternals ● Система может собирать стеки вызовов (AppVerifier). Требуется перезапуск процесса ● Если есть возможность подключить отладчик – пользуемся! Проще, перезапуск приложение не требуется
- 22. Утечка памяти 22
- 23. Утечка памяти 23 ● Основным признаком утечки является постоянное увеличение объема памяти, используемой приложением. ● Исследование данной категории проблем предполагает отслеживание выделения и освобождение памяти, сравнение состояния памяти в разные моменты времени (так называемых memory snapshots) ● Два основных подхода для получения информации о работе с динамической памятью: перехват системных вызовов и использование функционала системы по сбору стеков вызовов (конфигурируется GFlags/AppVerifier/UMDH) ● В некоторых случаях не требуется предварительная конфигурация системы
- 25. Утилита UMDH 25 ● Входит в состав Debugging Tools for Windows ● Работает на уровне Heap Manager’a ● Основная идея следующая: ○ Сделать снимок использования памяти перед воспроизведением (контрольная точка А) ○ Сделать снимок использования памяти после воспроизведения (контрольная точка Б) ○ Сравнить полученные снимки.
- 26. Утилита UMDH – перед использованием 26 ● Перед использованием утилиты необходимо сконфигурировать пути поиска отлодочных символов в переменной окружения _NT_SYMBOL_PATH (на стороне разработчика) ● Также необходимо сконфигурировать систему сохранять стеки вызовов при выделении памяти (Application Verifier или gflags). В случае отсутствия конфигурации утилита выполнит конфигурацию самостоятельно.
- 27. Утилита UMDH. Pецепт 27 На машине с воспроизведением: ● UMDH -p:PID > first_snapshot_filename ● Воспроизвести утечку памяти ● UMDH -p:PID > second_snapshot_filename На машине разработчика: ● UMDH first_snapshot_filename second_snapshot_filename > diff ● Проанализировать файл diff
- 28. Подведем итог 28 ● Поиск причины утечки памяти может быть сложным из-за обилия API / уровней работы с динамической памятью ● Рекомендуется использовать UMDH для быстрого исследования: не требует предварительной конфигурации и перезапуска процесса
- 30. Взаимоблокировки 31 Выделим следующие ситуации: ● Взаимоблокировки при использовании CRITICAL_SECTION, в рамках одного процесса ● Взаимоблокировки при использовании объектов ядра, межпроцессные взаимоблокировки ● Взаимоблокировки с использованием примитивов синхронизации С++
- 31. Взаимоблокировки 32 ● В любом случае сделать дамп памяти процесса ● При анализе дампа распечатать все потоки. Выделить заблокированные. ● В случае c CRITICAL_SECTION использовать команды !cs, !locks. Данный примитив синхронизации содержит информацию о текущем владельце. Раскручивание таких цепочек наименее трудоемкое ● В случае использования объектов ядра дампа памяти процесса может быть недостаточно, необходимо знание логики приложения для анализа цепочки блокировки. ● При наличии межпроцессной блокировки могут понадобиться дампы всех задействованных процессов и полный дамп памяти системы.
- 32. std::mutex и std::recursive_mutex 33 ● Объекты синхронизации с++ активно используют «родные» для Windows примитивы ● Иногда могут содержать информацию о потоке владельце (зависит от реализации) ● Из коробки, windbg может найти владельца для std::recursive_mutex (проверено для VS2017 + WinDbg Preview) ● Немного смекалки – и ту же информацию можно получить и о std::mutex. Подсказка в файле %windbg_root%visualizersstl.natvis и немного позже в докладе
- 33. std::*mutex 34
- 34. Подведем итог 35 ● При блокировке потоков получить дамп ● В большинстве случаев необходимо знание кода для восстановления цепочки ожидания ● Объекты синхронизации С++ могут содержать информации о владельце
- 35. Аварийное завершение 36 Кабы знал, где упасть, соломки бы подостлал Народная поговорка
- 36. Аварийное завершение 37 ● При возникновении в потоке исключительной ситуации система начинает раскрутку стека в поисках обработчика исключения (англ. exception handler). ● Если ни один из фильтров не обработает исключение, будет вызван фильтр необработанных исключений ● По умолчанию фильтр необработанных исключений запускает процесс werfault.exe, который создает отчет об ошибке. ● Процесс принудительно завершается При аварийном завершении приложения во многих случаях достаточно дампа памяти, содержащего информацию о необработанном исключении.
- 37. Аварийное завершение 38 Получить дамп при аварийном завершении можно следующими способами: ● Сконфигурировать Windows error reporting ● Сконфигурировать Just in time debugger ● Реализовать свой фильтр необработанных исключений
- 38. Windows error reporting 39 Конфигурация создания дампов памяти при аварийном завершении находится: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows Windows Error ReportingLocalDumps [ImageName.exe] DumpFolder Путь к каталогу, в котором будут сохраняться дампы REG_EXPAND_SZ DumpCount Максимальное количество дампов. REG_DWORD DumpType Тип дампа памяти: • 0: Custom dump • 1: Mini dump • 2: Full dump REG_DWORD
- 39. Just in time debugger 40 Функция в ОС Windows позволяет автоматически запустить отладчик и подключить его к приложению при возникновении необработанного исключения Отладчики имеют возможность зарегестрировать себя самостоятельно. (для windbg это параметр командной строки -I) В реестре конфигурация сохраняется в HKLMSoftwareMicrosoftWindows NTCurrentVersionAeDebug HKLMSoftwareWow6432NodeMicrosoftWindows NTCurrentVersionAeDebug
- 40. Just in time debugger. Visual Studio 41
- 41. OK, у нас есть дамп... 42 Начинаем с !analyze –v. Данная команда проведет первичный анализ дампа. В случае с аварийным завершением постарается восстановить контекст процессора на момент возникновения исключительной ситуации. Дальнейшие действия зависят от конкретной ситуации.
- 42. Memory corruption: возможные причины 43 • Нарушение соглашения о вызовах (поврежден стек) • Неинициализированные переменные • Переполнение буфера • Использование памяти после освобождения • Возврат из функции ссылки / указателя на локальную переменную • «Забытые» указатели на переменные, которые могут измениться другими потоками (незавершенный аснхронный ввод-вывод + отсутствие вызова CancelIO) – также источник heap corruption
- 43. Stack corruption 44 • Многие нарушения обнаруживаются компилятором • В дампе памяти повреждение стека может быть легко определено командой k. • При выходе из функции содержимое стека не стирается, меняется только значение регистра ESP. Как следствие, можно попытаться восстановить стек !teb – показать thread environment block. Это даст нам границы стека dps – print pointer resolve symbol. k – распечатать стек. Поддерживает переопределение ESP/EBP d* - распечатать память
- 44. Heap corruption 45 Пожалуй, самый тяжелый для отладки класс проблем При относительно стабильном воспроизведении рекомендуется использовать application verifier / gflags для конфигурирования отладочной кучи Использование отладочной кучи несколько влияет на производительность приложения, однако позволяет получить намного больше информации о блоках динамической памяти, включая стек вызовов. Также предполагается заполнение блоков памяти специальными паттернами, упрощающую идентификацию их начала и конца
- 45. Конфигурирование отладочной кучи (gflags) 46
- 46. Стек вызовов при выделении блока (дамп) 47 Значение, возвращенное функцией malloc
- 47. Недостатки дампов памяти 49 ● Дамп файл содержит снимок состояния программы в определенный момент времени ● Невозможно проследить развитие дефекта во времени
- 48. Time travel debugging 50 ● Во время отладки Windbg записывает выполнение программы в лог файл, который позже можно повторно воспроизвести. ● Позволяет выполнять инструкции в обратном порядке. Легко понять причины, которые привели к ошибке. ● Включает модель данных, позволяющую выполнять LINQ запросы к сохраненной трассировке ● Значительно влияет на производительность (!) . Отлично подходит для отладки предсказуемых дефектов
- 49. Dump file vs TTD trace 51
- 50. 52 C:>TTD_DEMO
- 51. Автоматизация анализа дампов памяти 53 ● Экономия времени на поиск источника проблемы: быстрое определение модуля с ошибкой и ответственного разработчика ● Позволяет приоритезировать задачи: определение дампов с одинаковой проблемой и автоматическая группировка ● Экономия времени на анализ аварийных завершений: разработчики даже не открывают дампы с уже известными проблемами Для автоматизации используется встроенный скриптовый язык. Можно также применить расширение PyKd и язык Python
- 52. Hапоследок 54 Пару практических советов, как сделать отладку приятнее ● Cmdtree ● Произвольные визуализации
- 53. 55 C:>DEMO
- 54. + + + + + + + Спасибо за внимание! golovach@checkpoint.com + 56
Editor's Notes
- #4: Упомянуть о стоимости исправления дефекта с ссылкой на, хотя бы, PVS-studio Рассказать о неловких ситуациях во время remote (не потерять бы лицо и заказчика)