Как работают отладчики? Отладка программ

Изучение механизма работы программных инструментов — наиболее трудная часть отладочного процесса. Только понимая возможности и ограничения инструментов, можно получать от них большую отдачу и тратить меньше времени на отладку. Как правило, отладчики чрезвычайно полезны, но могут привести к довольно тонким проблемам, заводящим программиста в тупик. В этой главе показано, что такое отладчик и как различные отладчики работают в операционных системах Win32 (32-разрядных операционных системах Windows фирмы Microsoft).

При этом сосредоточимся на тех специальных свойствах отладчиков вообще, которые включены, когда под управлением последних выполняется какой-то программный процесс. Кроме того, здесь поясняются возможности усиления некоторых свойств 32-разрядных операционных систем Windows, позволяющие облегчить процесс отладки. Будут представлены два авторских отладчика, исходный код которых можно найти на сопровождающем компакт-диске. Первый (MinDBG) имеет достаточные возможности для того, чтобы его называли отладчиком. Второй (WDBG) — пример отладчика Microsoft Windows, который делает почти все, что и реальный системный отладчик, включая манипулирование таблицами символов, обработку точек прерывания, генерацию кода дизассемблера и координирование с графическим интерфейсом пользователя (GUI). При обсуждении WDBG мы покажем, как работают точки прерывания, и обсудим, что представляют собой различные файлы символов (symbol files).

Прежде чем переходить к основному материалу этой главы, определим два стандартных термина, которые будут часто использоваться в этой книге: основной (или базовый) отладчик (debugger) и подчиненный отладчик (debuggee). Проще говоря, основной отладчик — это процесс, который в отладочном отношении может контролировать другой процесс, а подчиненный отладчик — это процесс, запускаемый под основным отладчиком. В некоторых операционных системах основной отладчик называют родительским процессом, а подчиненный — дочерним.

Если вы хоть немного программировали для Windows, то, вероятно, слышали о различных типах отладчиков, которые можно при этом использовать. В мире Windows доступны два типа отладчиков: отладчики режима пользователя (user-mode debuggers) и отладчики режима ядра (kernel-mode debuggers).

Большинству разработчиков больше знакомы отладчики пользовательского режима. Не удивительно, что отладчики этого режима предназначены для отладки приложений пользовательского режима (user-mode applications). Главный пример отладчика режима пользователя — отладчик Microsoft Visual C++. Отладчики режима ядра, как следует из их названия, — это такие отладчики, которые позволяют отлаживать ядро операционной системы. Они используются главным образом теми, кто пишет (и отлаживает, конечно) драйверы устройств.

Отладчики режима пользователя предназначены для отладки любого приложения, выполняющегося в режиме пользователя, включая любые GUI-программы, а также такие не совсем обычные приложения, как службы (services) Windows 2000. В общем случае, отладчики этого типа поддерживают графический интерфейс пользователя (GUI1). Главный признак таких отладчиков — они используют отладочный интерфейс прикладного программирования (отладочный API) Win32. Поскольку операционная система помечает подчиненный отладчик как "выполняющийся в специальном режиме", то, чтобы выяснить, выполняется ли ваш процесс под отладчиком, можно использовать API-функцию IsDebuggerPresent.

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

Для интерпретируемых языков и исполнительных (run-time) систем, которые используют подход виртуальной машины, полную отладочную среду обеспечивают сами виртуальные машины, и они не используют отладочный API Win32. Вот некоторые примеры таких типов сред: виртуальные Java-машины (JVM) фирм Microsoft или Sun, среда сценариев для Web-приложений фирмы Microsoft, и интерпретатор р-кода в системе Microsoft Visual Basic.

Мы доберемся до отладки в Visual Basic в главе 7, но знайте, что интерфейс р-кода Visual Basic не документирован. Не будем вникать в отладочные интерфейсы Java и сценариев, эти темы выходят за рамки данной книги. Дополнительную информацию по отладке и профилированию Microsoft JVM ищите в разделе "Debugging and Profiling Java Applications" (Отладка и профилирование приложений Java) на MSDN. Набор таких интерфейсов весьма богат и разнообразен и позволяет полностью управлять работой JVM. Информацию о написании отладчика сценария можно найти в разделе MSDN "Active Script Debugging API Objects" (Активные объекты отладочных API-сценариев). Подобно JVM, объекты отладчика сценариев обеспечивают богатый интерфейс для сценариев доступа и документирования.

Отладочный API Win32 использует удивительно много программ. К ним относятся: отладчик Visual C++, который подробно рассматривается в главах 5 и 6; отладчик Windows (WinDBG), который обсуждается в следующем разделе (посвященном отладчику режима ядра); программа BoundsChecker фирмы Compuware NuMega; программа Platform SDK HeapWalker; программа Platform SDK Depends; отладчики Borland Delphi и C++ Builder, а также символический отладчик NT Symbolic Debugger (NTSD). Я уверен, что их намного больше.

Отладчики режима ядра находятся между CPU и операционной системой. Это означает, что, когда вы останавливаете отладчик режима ядра, операционная система также полностью останавливается. Нетрудно сообразить, что переход операционной системы к резкому останову полезен, когда вы работаете с таймером и над проблемами синхронизации. Все-таки, за исключением одного отладчика, о котором будет рассказано ниже (в разделе "Отладчик SoftlCE" данной главы), нельзя отлаживать код пользовательского режима с помощью отладчиков режима ядра.

Отладчиков режима ядра не так много. Вот некоторые из них: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG и SoftlCE. Каждый из этих отладчиков кратко описан в следующих разделах.

WDEB386 — это отладчик режима ядра Windows 98, распространяемый в составе Platform SDK. Этот отладчик полезен только для разработчиков, пишущих драйверы виртуальных устройств Windows 98 (VxD). Подобно большинству отладчиков режима ядра для операционных систем Windows, отладчик WDEB386 требует для работы две машины и нуль-модемный кабель. Две машины необходимы потому, что часть отладчика, которая выполняется на целевой машине, имеет ограниченный доступ к ее аппаратным средствам, так что он посылает свой вывод и получает команды от другой машины.

Отладчик WDEB386 имеет интересную историю. Он начинался как внутренний фоновый инструмент Microsoft в эпоху Windows 3.0. Его было трудно использовать, и он не имел достаточной поддержки для отладки исходного кода и других приятных свойств, которыми нас испортили отладчики Visual C++ и Visual Basic.

"Точечные" (DOT) команды — наиболее важная особенность WDEB386. Через прерывание INT 41 можно расширять WDEB386 с целью добавления команд. Эта расширяемость позволяет авторам VxD-драйверов создавать заказные отладочные команды, которые дают им свободный доступ к информации в их виртуальных устройствах. Отладочная версия Windows 98 поддерживает множество DOT-команд, которые позволяют наблюдать точное состояние операционной системы в любой точке процесса отладки.

Windows 2000 отличается от Windows 98 тем, что реально действующая часть отладчика режима ядра является частью NTOSKRNL.EXE — файла главного ядра операционной системы Windows 2000. Этот отладчик доступен как в свободных (выпускных), так и в проверенных (отладочных) конфигурациях операционной системы. Чтобы включить отладку в режиме ядра, установите параметр загрузчика /DEBUG в BOOT.INI и, дополнительно, опцию загрузчика /DEBUGPORT, если необходимо установить значение коммуникационного порта отладчика режима ядра, отличающееся от умалчиваемого (СОМ1). I386KD выполняется на своей собственной машине и сообщается с машиной Windows 2000 через кабель нуль-модема.

Отладчик режима ядра NTOSKRNL.EXE делает только то, что достаточно для управления CPU, так чтобы операционная система могла быть отлажена. Большая часть отладочной работы — обработка символов, расширенные точки прерывания и дизассемблирование — выполняется на стороне 1386KD. Одно время Windows NT 4 Device Driver Kit (DDK) документировал протокол, используемый в кабеле нуль-модема. Однако Microsoft больше его не документирует.

Мощь 1386KD очевидна, если посмотреть на все команды, которые он предлагает для доступа к внутреннему состоянию Windows 2000. Знание механизма работы драйверов устройств в Windows 2000 поможет программисту следить за выводом многих команд. Не смотря на всю свою мощь, i386KD почти никогда не применяется, потому что это консольное приложение, которое очень утомительно использовать для отладок исходного уровня.

WinDBG — это отладчик, который поставляется в составе Platform SDK. Можно также загрузить его с http://msdn.microsoft.com/developer/sdVdebidt.asp. Это гибридный отладчик, который может работать как в режиме ядра, так и в режиме пользователя, но WinDBG не позволяет отлаживать программы пользовательского режима и режима ядра одновременно. Для отладки в режиме ядра WinDBG предоставляет всю мощь отладчика i386KD, но с более легким в использовании внешним GUI-интерфейсом, который значительно упрощает отладку на уровне исходного кода. С помощью WinDBG можно выполнять отладку драйверов устройств почти так же легко, как для приложений пользовательского режима.

Как отладчик пользовательского режима WinDBG великолепен, и я настоятельно рекомендую установить его, если вы этого еще не сделали. WinDBG — более мощный отладчик, по сравнению с отладчиком Visual C++, в том отношении, что он показывает намного больше информации в процессе отладки. Однако за эту мощь надо платить: WinDBG труднее использовать, чем отладчик Visual C++. Тем не менее я посоветовал бы потратить время на изучение WinDBG. Это может окупиться намного более быстрым исправлением ошибок, чем с помощью отладчика Visual C++. Лично я провожу, в среднем, приблизительно 70% времени в отладчике Visual C++, а остальное — в WinDBG.

При первом запуске WinDBG можно заметить, что у него имеется специальное окно команд (Command). Подобно отладчику Visual C++, WinDBG выполняет отладку на уровне исходного кода. Однако реальная мощь WinDBG проявляется в интерфейсе окна его команд. Почувствовав удобство различных команд, вы вскоре обнаружите, что с помощью окна Command можно выполнять отладку намного быстрее, чем с помощью только GUI-интерфейса.

Возможности окна команд WinDBG возрастают, если добавить в него свои собственные команды, называемые WinDBG-расширениями. В то время как отладчик Visual C++ не очень гибок при остановке отлаживаемого процесса, в WinDBG имеется полный набор API-функций, позволяющих использовать все функциональные возможности отладчика, включая дизассемблер, символьную машину и машину трассировки стека. Дополнительную информацию о WinDBG-расширениях можно найти в разделе "Debugger Extension" (Расширение отладчика) на MSDN.

В некоторых ситуациях лучше использовать WinDBG, а не отладчик Visual C++, потому что WinDBG поддерживает более мощный набор точек прерывания. Благодаря окну команд можно связывать команды с точкой прерывания. Это позволяет вывести отладку на совершенно новый уровень. Например, отлаживая программный модуль и выполняя многочисленные вызовы, очень удобно видеть значения каждого вызова без остановки приложения.

В WinDBG можно создать команду, связанную с точкой прерывания, для того чтобы вывести данные и затем возобновить выполнение программы. В этом случае в окне Command можно видеть поток всех значений данных, приводящих к проблеме.

В дополнение к лучшей расширяемости, чем у отладчика Visual C++, WinDBG имеет еще одно свойство, которое обязательно нужно рассмотреть, если приложение выполняется в Windows 2000 или Windows NT 4: WinDBG может читать файлы дампов пользовательского режима, созданные программой Dr. Watson. Это означает, что можно загружать в отладчик точное состояние программы во время аварийного прерывания, подробно его просмотреть и проанализировать. Дополнительную информацию о том, что нужно для установки этого свойства, можно найти в колонках "Bugslayer" журнала "Microsoft Systems Journal" ж декабрь 1999 и январь 2000.

В целом, с WinDBG работать намного сложнее, чем с отладчиком Visual C++. Однако я надеюсь, что пробудил интерес к WinDBG. Возможности, которые он предлагает, помогут найти решение некоторых очень неприятных проблем гораздо быстрее и легче, чем это можно было бы сделать с помощью одного отладчика Visual C++. Небольшие затраты на изучение WinDBG окупятся экономией огромного количества времени, когда дело дойдет до тяжелой аварийной ситуации.

SoftICE — коммерческий отладчик режима ядра фирмы Compuware NuMega. Это единственный известный мне коммерческий отладчик подобного типа, а также единственный отладчик режима ядра, который может работать на одной машине. Однако, в отличие от других отладчиков этого режима, SoftICE превосходно выполняет работу по отладке программ пользовательского режима. Как упоминалось ранее, отладчики режима ядра находятся между CPU и операционной системой. При отладке программы пользовательского режима SoftICE также находится между CPU и операционной системой и, таким образом, останавливает в случае необходимости всю операционную систему целиком.

На первый взгляд, нас мало должен беспокоить тот факт, что SoftICE может привести к остановке операционной системы. Но зададим такой вопрос: "Что случится, если нужно отладить код, работающий с таймером?" Если вы используете такую API-функцию, как SendMessageTimeout, то можете легко попасть в ситуацию тайм-аута, когда выполняете пошаговый проход другого потока с помощью типового GUI-отладчика. Работая с SoftICE, можно "шагать" везде где угодно, потому что таймер, с которым имеет дело SendMessageTimeout, не будет выполняться, пока вы работаете под SoftICE. SoftICE — единственный отладчик, который позволяет эффективно отлаживать многопоточные приложения. Сам факт, что SoftICE останавливает всю операционную систему, когда он активен, означает, что решение таймерных проблем становится гораздо более легким.

Другим преимуществом размещения SoftICE между CPU и операционной системой является то, что отладка межпроцессных взаимодействий становится очень легкой. Если вы занимаетесь СОМ-программированием с множеством внепроцессных служб, то можете легко устанавливать точки прерывания во всех процессах и выполнять пошаговые переходы между ними. Наконец, если нужно переходить от режима пользователя в режим ядра или обратно, то SoftICE делает такие переключения тривиально.

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

Другое важное преимущество SoftICE, по сравнению со всеми другими отладчиками, заключается в том, что он обладает феноменальной коллекцией информационных команд, которые позволяют видеть фактически все, что случается в операционной системе. Хотя в отладчиках 1386KD и WinDBG довольно много таких команд, в SoftICE их намного больше. В SoftICE можно просматривать почти все — от состояния всех событий синхронизации до полной HWND-информации и расширенной информации о любом потоке в системе.

Нетрудно догадаться, что за весь этот набор замечательных свойств нужно чем-то платить. Подобно всем отладчикам режима ядра, SoftICE довольно сложно изучать, потому что во время выполнения он, по существу, становится и собственной операционной системой. Однако игра стоит свеч.

Windows 2000 содержит набор специальных API-функций, предназначенных для использования в отладчиках. Кроме того, эта операционная система обладает рядом свойств, весьма полезных для поиска проблемных приложений. Некоторые из них мало знакомы разработчикам.

Проверка динамических областей памяти в Windows 2000

Когда приложение стартует под отладчиком, Windows 2000 включает проверку специальной отладочной области динамического распределения памяти (debug heap) операционной системы. Эта область не совпадает с отладочной heap-памятью С-библиотеки времени выполнения. Код этой области создается с помощью специальной API-функции — HeapCreate. О динамической области ("куче") С-библиотеки времени выполнения речь пойдет в главе 15. Поскольку отладочные heap-области используются процессами Windows 2000 довольно широко, с их информацией приходится сталкиваться часто, вот почему так важно поподробнее ознакомиться с ними. Если вы подключаете отладчик к приложению, а не стартуете приложение под отладчиком, то проверка отладочной heap-области в операционной системе Windows 2000 активизирована не будет.

Если проверка отладочной динамической области включена, то приложение будет выполняться немного медленнее, потому что когда в приложении вызывается функция HeapFree, то приходится дополнительно проверять корректность "кучи". В листинге 4-1 показан пример программы, которая портит память. Если эта программа выполняется под отладчиком, то нетрудно заметить, что функция DebugBreak вызывается дважды (на первом же вызове функции HeapFree). Ниже показан вывод, по которому видно, что при работе с heap-областью возникли некоторые проблемы.

Если эта программа выполняется вне отладчика, то она завершается без сообщений о каких-либо проблемах.

Если вы используете в Windows 2000 свои собственные2 heap-области, то для того чтобы получить более полный диагностический вывод, можно включить несколько дополнительных флажков. Для этого в Platform SDK включена небольшая утилита GFLAGS.EXE. С ее помощью можно установить несколько глобальных флажков, проверяемых операционной системой при первом запуске приложения. Установки, выполненные этой утилитой для файла HEAPER.EXE, показаны на рис. 4.1.

Heap - "куча", область динамически распределяемой памяти. — Пер.

Что вполне возможно, т. к. не только отладчики, но и любые приложения могут вызывать функцию HeapCreate. — Пер.

Этот набор инструментов вы можете найти на сопровождающем CD. — Пер.

Это загрузочный модуль, частью которого является функция, показанная в листинге 4-1. — Пер.

Многие опции кнопок System Registry и Kernel Mode переключателя Destination окна Global Flags являются глобальными. Нужно проявлять особую осторожность при их установке, потому что они могут оказать решающее влияние на производительность системы. Установка переключателя Destination в положение Image File Options намного безопаснее, потому что все установки влияют только на один модуль (имя которого указано в соседнем поле Image File Name).

Листинг 4-1. Пример разрушения heap-области Windows 2000

// Распределить память для блока размером в 10 байтов.

// Записать 12 байт в 10-байтовый блок (переполнение heap-области).

// Освободить первый блок. Это обращение к HeapFree будет

// инициировать точку прерывания в коде отладочной heap-области

// Освободить второй блок. Заметим, что этот вызов не будет

// Освободить фиктивный блок. Заметим, что этот вызов не будет

Если установить те же флажки, что на рис. 4.1, и повторить выполнение HEAPER.EXE, то будет получен следующий, более многословный вывод:

Содержимое листинга объясняют названия флажков, установленных панелью Global Flags.

Обсуждая программу GFLAGS.EXE, я хочу указать на одну очень полезную опцию — Show Loader Snaps. Если вы установите этот флажок и выполните приложение, то увидите то, что называют снимком (snap) приложения, в котором видно, где Windows 2000 загружает DLL-файлы и как она начинает организацию импорта. Если необходимо точно видеть, что делает загрузчик Windows 2000 при загрузке приложения (особенно в том случае, когда в нем обнаружена проблема), то включение этой опции может оказаться весьма полезным мероприятием. Дополнительную информацию по снимкам загрузчика можно получить в колонке Мэта Пьетрека "Under the Hood" в сентябрьском выпуске Microsoft Systems Journal за 1999 год.

Автоматический запуск приложений в отладчике

Самыми трудными для отладки типами приложений являются те приложения, которые запускаются другим процессом. В эту категорию нападают службы Windows 2000 и внепроцессные (out-of-process) СОМ-серверы (СОМ out-of-process servers). Чтобы заставить отладчик прикрепиться к процессу, во многих случаях можно использовать API-функцию DebugBreak. В двух случаях, однако, эта функция работать не будет. Во-первых, она иногда не работает со службами Windows 2000. Если нужно отладить запуск службы, то вызов DebugBreak присоединит отладчик, но к тому времени, когда отладчик запустится, может быть исчерпан интервал тайм-аута службы, и Windows 2000 остановит ее. Во-вторых, DebugBreak не будет работать, когда нужно отлаживать внепроцессный СОМ-сервер. Если вы вызовете DebugBreak, обработчик СОМ-ошибок отловит исключение точки прерывания и завершит СОМ-сервер. К счастью, Windows 2000 позволяет указать, что приложение должно стартовать в отладчике. Это свойство позволяет начать отладку прямо с первой инструкции. Однако, прежде чем вы включите это свойство для службы Windows 2000, удостоверьтесь, что в этой службе сконфигурирована возможность взаимодействия с рабочим столом Windows 2000.

Свойство запуска с отладчиком можно включить двумя способами. Самый легкий — запустить утилиту GFLAGS.EXE и выбрать переключатель Image File Options (см. рис. 4.1). После ввода в редактируемое поле Image File Name имени двоичного файла программы установите флажок Debugger в группе Image Debugger Options) и введите в редактируемое поле рядом с этим флажком полный путь к отладчику.

Более трудный способ: нужно вручную установить необходимые параметры з подходящие разделы реестра (с помощью редактора RegEdit). В разделе

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NTXCurrent Version\Image Tile Execution Options

создайте подраздел, имя которого совпадает с именем файла вашего приложения. Например, если имя приложения — FOO.EXE, то имя подраздела реестра тоже FOO.EXE. В этом подразделе создайте новый строковый параметр с именем Debugger. В диалоговом окне Изменение строкового параметра введите с клавиатуры полное (вместе с путем к каталогу) имя файла выбранного вами отладчика. Если вы указали GFLAGS.EXE и установили некоторые глобальные опции, то сможете заметить в ключе вашего приложения строчное значение GiobaiFiag.

Теперь при запуске вашего приложения автоматически загружается и запускается и отладчик. Опции командной строки для отладчика также можно определить в строковом параметре Debugger (вслед за именем программы отладчика). Например, для того чтобы использовать отладчик WinDBG и автоматически инициировать отладку, как только стартует WinDBG, нужно в диалоговом окне изменения строкового параметра Debugger ввести значение d:\platform sdk\bin\windbg.exe -g.

Иногда нужно быстро войти в отладчик. Если вы отлаживаете консольные приложения, то нажатие клавиш <Ctrl>+<C> или <Ctrl>+<Break> вызовет специальное исключение (с именем DBG_CONTROL_C) . Это исключение переведет вас прямо в отладчик и позволит стартовать отладку.

Полезным свойством как Windows 2000, так и Windows NT 4 является возможность в любое время переходить в отладчик также и в GUI-приложениях. При выполнении под отладчиком нажатие клавиши <F12> приводит (по умолчанию) к вызову функции DebugBreak. Интересный аспект обработки этой клавиши заключается в том, что, даже если вы используете ее как акселератор или как-то иначе обрабатываете сообщения клавиатуры для этой клавиши, она все еще будет подключать вас к отладчику.

В Windows NT 4 быстрая клавиша прерывания <F12> назначена по умолчанию, однако в Windows 2000 вы можете сами определить, какую клавишу следует использовать для этих целей. Для чего в разделе реестра

установите для параметра userDebuggerHotKey значение кода клавиши (VK_*). Например, чтобы использовать клавишу <Scroll Lock> для подключения к отладчику, следует установить значение UserDebuggerHotKey равным 0x91. Изменения вступают в силу после перезагрузки компьютера.

Знаете ли Вы, что примитивные конструкторы - это операции, которые создают объекты, соответствующего им типа, не используя никаких объектов в качестве аргументов. Примером такой операции является создание пустого списка.