Май - Xakep Online

coding
обстоятельствах приводящая к потере нуля
в конце ASCIIZ-строки. Но поскольку за ней
следовало двойное слово, заброшенное на
стек командой PUSH reg16, и я отлаживал
программу на процессоре, очищающем
старший разряд, то все работало более или
менее нормально (2 байта мусора, появляющихся
в конце строки, никому не мешали). Но
вот при запуске на другом процессоре, где
завершающего нуля не оказывалось, возникала
критическая ситуация, завершающаяся
исключением.
Или вот: незначительные различия в реализации
«плавающих» команд на различных
процессорах могут привести к странному
поведению программы, которое будет
невозможно воспроизвести на любом другом
процессоре!
Про разгон, дефекты памяти и т.д. я вообще
молчу! Никогда нельзя быть уверенным в
том, что после выполнения «a=6; a=a+3;»
в переменной а окажется именно 9, а не
83737382. И виноват тут может быть не
только процессор, но и «удар по памяти»,
когда совершенно посторонняя функция,
обратившись по неинициализированному
указателю, запишет что-то в чужую область
данных.
Естественно, самотестирование занимает
некоторое время, и для достижения максимальной
производительности я использую
его в том случае, если предыдущий запуск
программы завершился в аварийном режиме.
Кроме того, на всякий непредвиденный
случай присутствует недокументированный
флаг, форсирующий самотестирование, даже
если предыдущий запуск был завершен
нормально.
Функции самотестирования не раз выручали
меня и помогли мне сэкономить колоссальное
количество времени, поскольку ряд ошибок
был связан с особенностями конкретного
оборудования, то есть причина крылась вне
исходного кода программы.
03
секреты
отладочной печати
Отладочная печать — великолепное изобретение,
появившееся еще в те времена, когда
интерактивных отладчиков не существовало
и в помине, а отлаживать было надо.
Большинство программистов использует
тривиальную запись в текстовый log-файл
или API-функцию OutputDebugString. Первый
метод, естественно, лучше, поскольку он
не требует наличия отладчика или специальной
утилиты для перехвата отладочной
печати, которую конечному пользователю
нужно устанавливать на свой компьютер. Мы
же ведь не собираемся исключать отладочную
печать из финальной версии, верно?
Естественно, не собираемся! Достаточно добавить
специальный ключ командой строки,
секретную комбинацию клавиш или вполне
честную опцию в настройках программы.
Лог лучше всего вести в текстовой форме.
Так пользователю будет проще пересылать
его нам по почте и он сможет убедиться, что
там нет ничего такого, чего бы он не хотел
разглашать.
Вот только… при возникновении критической
ошибки система завершает работу
приложения еще до того, как будут сброшены
дисковые буферы. Даже использование функции
fflush ничего не решает (а вот скорость
программы замедляет весьма существенно).
Как же быть?! Да очень просто: создать в
shared-memory кольцевой буфер заданного
размера и весь отладочный вывод направлять
туда, читая его с помощью дочернего
процесса. Тогда, при аварийном завершении
материнского процесса, shared-memory не
будет освобождена системой и дочерний
процесс успеет принять последнее отладочное
сообщение, отправленное упавшей
программой. К тому же этот метод работает
намного быстрее прямой записи на диск.
А почему буфер должен быть именно кольцевым?!
В общем, это не требование, а так,
простое пожелание. Обычно нас интересует
не весь отладочный вывод целиком, а
события, непосредственно предшествующие
падению. Но при интенсивном отладочном
выводе полный размер лога может достигать
десятков мегабайт, большая часть которых
не несет никакой полезной нагрузки, так что
лучше заранее исключить ее, замкнув буфер
в кольцо.
04
автоматический трассировщик
— это просто
В самых ответственных случаях программу,
поставляемую заказчику, имеет смысл
снабдить простейшим автоматическим
трассировщиком, на создание которого уйдет
не больше одного вечера. Просто взводим
флаг трассировки (TF) и отлавливаем
отладочные исключения штатными средствами
операционной системы (через SEH),
записывая: а) адрес машинной команды;
б) содержимое регистров; в) адрес ячейки
памяти, к которой она обращается.
Когда трассировка из прикладного уровня
дойдет до ядра, процессор самостоятельно
опустит флаг трассировки на время
прохождения нулевого кольца и потом
поднимет его при возвращении на прикладной
уровень, так что предусматривать
специальную обработку для исключения
системных вызов из списка трассируемых
функций не надо.
Естественно, трассировка на несколько
порядков (!) замедляет скорость работы
программы и потому должна включаться
специальной комбинацией клавиш, которую
пользователь нажимает в тот момент,
когда программа приближается к месту
сбоя на максимально близкое расстояние.
А для этого пользователю придется
воспроизвести ситуацию, при которой
возникает ошибка. Если же ему это сделать
не удастся, что ж! Включаем трассировщик
при старте программы специальным
ключом командой строки и пишет результат
трассировки в кольцевой буфер, который
внимательно изучаем.
Располагая информацией о ходе
выполнения программы, содержимом
регистров и ячеек памяти, мы сможем
поймать любую ошибку, какой бы заковыристой
она ни была, ведь фактически
мы отлаживаем программу на
клиентской стороне в неинтерактивном
режиме. При желании (если жаба душит)
трассировщик можно реализовать в
виде отдельной динамической библиотеки,
высылаемой клиенту только при
возникновении серьезных проблем. То
же самое, кстати, относится к функциям
самодиагностики.
Понятное дело, программа, защищенная
протекторами, содержащими антиотладочные
приемы, с автоматическим трассировщиком
работать не будет. Так что придется
отказаться или от протекторов, или от
трассировки, либо же надо писать «умный»
трассировщик, обходящий антиотладочные
приемы, но это уже серьезная задача,
решение которой может затянуться не на
одну неделю. z
xàêåð 05 /101/ 07
/ 133