Отладка on Алексей Пахунов

Когда 1.0 = 0.0

Mon, 16 Dec 2019 22:49:36 -0800

Столкнулся недавно с новой для себя областью - ловлей багов в компиляторе. Ловить баг в процессоре мне уже доводилось, а вот с компиляторами до недавнего времени как-то везло.

Началось все очень прозаично. В нашем репозитории есть своя реализация умного указателя. Ну, вы знаете, как это бывает. Обычная история на самом деле… Этот класс был написан в древние времена, тогда и С++03 еще на свете не было. С тех пор уже и С++17 появился и С++20 не за горами, но класс по-прежнему активно используется. Мы его давно хотели заменить на что-нибудь более стандартное и современное, но все руки не доходили. “Работает - не трожь”.

В один прекрасный день в этом классе нашлось неопределенное поведение, что стало последней каплей, ~~переломившей верблюду соломинку~~. Указатель был переписан на корню и стал тонкой оберткой вокруг std::shared_ptr<>. На следующий же день сломался один неприметный юнит тест на одной из платформ. Причем на первый взгляд никакого отношения к переписанному указателю этот тест не имел. Но от фактов было трудно отвертеться. С новым указателем тест падал, а со старым - нет.

Как я провел прошлую пятницу

Sat, 07 Jul 2018 17:09:38 -0700

Расскажу как я провел прошлую пятницу. Провел я её пытаясь понять, почему простой как доска тест-кейс не работает.

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

Такие тест-кейсы, естественно, не пишутся с нуля. Кейс набирается из уже готовых, давно написанных блоков. Что может быть очень простым делом (если есть готовый шаблон), или не очень простым (когда такой шаблон нужно создать самому). В этот раз случился как раз второй вариант. Когда все компоненты теста правильно соединены остается только написать код, который ждет наступления интересных событий и реагирует на них нужным образом.

К пятнице я добрался до момента, когда сценарий тест-кейса уже написан, но еще не работает. Сценарий вылетал по таймауту ожидая наступления одного из событий. При этом телеметрия четко показывала, что событие наступило и у теста был вагон времени, чтобы это заметить. Интересно, что точно такой же код, отслеживающий другую телеметрию работал как часы. Хм.

Отладка злого бага в Go runtime

Mon, 04 Dec 2017 22:50:05 -0800

Отличная статья про ловлю злого бага в Go runtime. Мне больше всего понравился момент, когда выясняется, что ошибочное поведение зависит от значения флага CONFIG_OPTIMIZE_INLINING. Вроде бы и вот она причина, и вместе с тем значение флага никак не указывает на проблемный участок кода. Автор расследования находит отличный выход из положения…

rr

Sun, 07 May 2017 18:56:38 -0700

Недавно наткнулся на rr (Record and Replay Framework) от Mozilla и я вам скажу, что это просто незаменимый инструмент для ловли неуловимых багов в отладчике. Это не первый и не единственный инструмент подобного плана. Соответствующая страница проекта описывает десятка три альтернатив. Из этого списка мне раньше доводилось работать только с iDNA, который впоследствии стал Time Travel Tracing (TTT). TTT мог записать процесс выполнения программы с точностью до инструкции и воспроизвести его в точности в прямом и обратном направлении. TTT был просто незаменим для ловли сложных багов и его главным недостатком было то, что TTT был внутренним инструментом, который Microsoft так и не выпустила как отдельный продукт.

rr тоже может записать выполнение процесса с точностью до инструкции и проиграть его назад и вперед. rr требует современного процессора, причем обязательно Intel, так как использует performance counters которые не реализованы в других процессорах. ARM и другие архитектуры тоже не поддерживаются. В обмен на это, rr практически не замедляет записываемый процесс. Скорость выполнения падает в 1.2 раза - сущие пустяки. Размер генерируемой записи тоже крайне скромен - в районе гигабайта за 10-15 минут выполнения “вычислительного” кода. Практически бесплатно. В пересчете на количество выполненных инструкций получается что-то вроде 0.1 бита на выполненную инструкцию.

Что интересно, rr базируется на очень простой идее: большая часть кода выполняется всегда одинаково. Если записать все случайные события (ввод/вывод, RDTSC, системный вызовы) и начальные условия (содержимое памяти), то процесс выполнения становится полностью детерминированным. Более детально можно почитать здесь: http://rr-project.org/rr.html.

Процесс отладки с помощью rr выглядит так:

Записываем процесс: rr record <program>
Запускаем запись в отладчике: rr replay
Проматываем до конца и смотрим чем вызван segfault.
Ставим watchpoint на память из которой читается плохой указатель.
Выполняем программу назад пока не сработает watchpoint.
Смотрим почему в память пишется плохой указатель и повторяем шаги 4-6 до победного конца.

Дополнительный бонус заключается в том, что все адреса при повторном воспроизведении сохраняются. Если нужная переменная находится по адресу 0x123fooba, то она там будет всегда. Отпадает необходимость выяснять где в памяти находится интересный кусок каждый раз при запуске отладчика. rr также может помечать вывод в stdout метками для быстрой перемотки в нужное место. Это помогает сопоставить код с интересными местами в лог файлах.

Само собой, у rr есть куча других ограничений. К примеру, он не работает под Windows, не поддерживаются все системные вызовы, не поддерживается циклическая запись (последние несколько минут выполнения процесса), поддерживается только одно процессорное ядро, и т.д. Тем не менее, если вы столкнулись с “невозможным” багом в Linux, rr - один из наиболее вероятных способов докопаться до источника проблемы.

Трассировка описателей (AKA handle tracing)

Tue, 04 Dec 2012 23:23:13 -0800

Начиная с Windows XP в ядро встроена поддержка трассировки описателей ядра (AKA handle tracing). Включение трассировки имеет двойной эффект. Во-первых, все операции с ядерными описателями сохраняются в циклический буфер (откуда их можно потом прочитать). Во-вторых, при любой попытке использовать несуществующий описатель генерируется исключение STATUS_INVALID_HANDLE. Фактически, проверка корректности операций с описателями в Application Verifier - это тонкая обертка вокруг функций трассировки, предоставляемых ядром. Расширение отладчика !htrace - аналогично.

Overclocking и его последствия

Tue, 25 Sep 2012 23:01:23 -0700

А сегодня мы с вами прослушаем лекцию о том, как избежать появления растительности на ладонях и чем её потом выводить…

Разбор crash dump-ов твоего приложения, собранных с пользовательских машин - занятие и увлекательное, и поучительное. Поучительное не столько потому, что демонстрирует твои собственные успехи во всей красе, но потому что не менее красиво показывает достижения других. Одновременно испытываешь и неловкость за содеянное (нахомутал, чего уж там) и гордость (да не так уж и нахомутал - посмотрите, как другие отличились), и облегчение (все одим миром мазаны). А сегодня мы разберем одно из часто встречающихся явлений - overclocking.

minidump.py

Thu, 12 Jul 2012 08:51:50 -0700

Если вам вдруг зачем-то понадобилось проанализировать структуру минидампа не загружая его в отладчик, начните вот с этой статьи: http://moyix.blogspot.com/2008/05/parsing-windows-minidumps.html. Автор написал скрипт на Python (на основе Construct) для анализа дампов, который распознает все потоки, описанные на MSDN (а также недокументированный поток, хранящий информацию об описателях окон). PS. Скрипт открывает дамп в текстовом режиме, что очевидно не будет работать на Windows. Чтобы этого не случилось, последняя строчка скипта должна выглядеть вот так:

Inception

Thu, 07 Apr 2011 23:38:25 -0700

Сижу я сегодня на работе, никого не трогаю, отладчиком отладчик отлаживаю. А что, отладчик - тоже человек программа. Тем более что немногим ранее я его немножко совсем поломал, пытаясь добавить поддержку некоей конфигурации, которая текущей реинкарнацией отладчика не поддерживается. Ну вот, запускаю я его примерно вот таким образом:

windbg.exe kd.exe -k com:port=com1,baud=115200

…и замечаю, что что-то не так. А именно - опять сломался наш корпоративный прокси. А я как раз хотел посмотреть в… ну скажем MSDN. Попробовал и так и сяк. Не работает, вылетает по таймауту. Ну хорошо, но тут начитают происходить еще более мистические вещи. Outlook вдруг перестает реагировать мышь и клавиатуру; IE вообще не запускается – процесс стартует, но окно не показывается. Несколько подозрительно для проблем с прокси.

NDIS, !ndiskd и DML

Sun, 06 Feb 2011 22:19:08 -0700

На работе понадобилось написать драйвер для сетевой карты. Я этого раньше никогда не делал и вообще с NDIS дела не имел. А тут такая возможность! Делюсь впечатлениями.

В общем и целом NDIS мне понравился. Интерфейсы довольно логичны, хотя и многочисленны. Взаимосвязь между разными компонентами в большинстве случаев после недолгой медитации становится довольно очевидной. Все структуры снабжены заголовком с сигнатурой, версией и размером, что, помимо заботы об обратной совместимости, означает меньше проблем с отладкой. При необходимости нужную структуру можно просто найти в памяти.

Отладка NMAKE скриптов

Sat, 30 Oct 2010 00:19:19 -0700

Раз уж я заговорил про BUILD и NMAKE, то вот несколько простых (и, в общем-то, очевидных) способов отладки NMAKE скриптов. Директива препроцессора !ERROR очень полезна, когда нужно выяснить доходит ли управление до интересующей нас линии скрипта. Директива выводит указанный текст в сообщении об ошибке (U1050) и останавливает NMAKE. !MESSAGE пригодится для дампа макросов в лог. Например: !MESSAGE BUILD_PASS = $(BUILD_PASS) Выведет в лог номер прохода (PASS0, PASS1 или PASS2), в случае, если NMAKE, был запущен через BUILD в билд-окружении WDK.

Как запустить «посторонний» бинарник под отладчиком в Visual Studio?

Tue, 14 Sep 2010 22:17:21 -0700

Visual Studio предлагает два основных отладочных сценария: Собрать проект и запустить результат под отладчиком. Присоединиться к уже запущеному процессу. Третьей опции, – запустить произвольный бинарник под отладчиком, явно не предлагается, что вызывает смятение и смуту в рядах программистов, не нюхавших WinDbg. Вот один из способов как этого можно добиться. Создаем новый проект. Тип проекта выбираем “Makefile project”. В качестве команды сборки, очистки и пересборки проекта указываем “echo.”. Можно с точкой; можно вывести какой-нибудь текст.

Про OutputDebugString

Wed, 14 Jul 2010 08:58:59 -0700

Тут интересная дискуссия про “неработающую” OutputDebugString завязалась в комментариях, если кто пропустил. Читать вот примерно отсюда.

Пошли мы как-то с коллегой на охоту…

Sun, 11 Jul 2010 14:10:10 -0700

Давно я про отладку не писал. Так вот пошли мы как-то с коллегой на Багов охотится. Вышли мы на двух таких матерых, опытных Багов. Их и помотали они нас…

Символы для release сборки

Tue, 05 Jan 2010 23:01:43 -0800

В очередной раз столкнулся с мифом, что, мол, release сборку невозможно отлаживать, так как символов нет. Значит так! Американцы на Луне были! Тьфу ты. В смысле, символы в release сборке включать: а) можно, б) нужно и в) полезно. Генерация отладочной информации не влияет на оптимизацию кода. Хотите, проверьте сами – сравните ассемблерные листинги с генерацией символов и без. Более того, случаи, когда это не так, однозначно трактуются как ошибки, которые можно смело отправлять в Microsoft.

Отладка на кофейной гуще

Fri, 22 May 2009 23:51:35 -0700

При определённой сноровке, можно отлаживать код прямо из любимого почтового клиента. На днях пришло письмо с вопросом. Некоторое приложение, будучи установленным в каталог отличный от “Program Files”, при запуске вызывало появление окна UAC с требованием повысить привилегии. Приложение работало нормально, в случае, если оно было установлено в “Program Files”. Как такое может быть?

Как отлаживать код незнакомых приложений?

Sun, 17 May 2009 22:43:10 -0700

… легко постукивая кувалдой.

Вопрос из почты:

Я пытаюсь приспособить windbg не для отладки, а для реверсинга незнакомых приложений, и постоянно упираюсь в то, что для удобной работы нужны символы, иначе windbg (в юзермоде, конечно) ничем не сильнее того же OllyDbg. Но, я надеюсь, что не все так плохо с этим отладчиком, и это у меня руки кривые.

Расширение для WinDbg: «Outline»

Sat, 16 May 2009 22:45:18 -0700

Мне частенько приходится разбираться с отладкой исключений, произошедших из-за порчи стека или на фоне порчи стека. В таких случаях обычно приходится трассировать стек вручную. Дело это муторное, поэтому я решил написать расширение для WinDbg, несколько облегчающее эту задачу.

Маленькие хитрости «посмертной» отладки

Sun, 08 Feb 2009 22:33:02 -0700

Как то заметил, что в списке запущенных процессов постоянно болтается три штуки cdb.exe:

CDB – это консольная версия WinDbg, которая у меня установлена в качестве «посмертного» отладчика (postmortem debugger).Обычно при этом падение приложения не проходит незамеченным - запускается консоль отладчика на весь экран. Трудно не заметить. В данном же случае, по всей видимости, фатальное исключение случалось в привилегированном процессе в отдельной сессии, соответственно и консоль создавалась в другой сессии.

Прелести отладки

Wed, 14 Jan 2009 23:25:05 -0700

Процесс отладки, насколько я могу судить, наполовину состоит невнятного мычания, пожимания плечами и чесания в затылке. Процентов двадцать занимает нудное «копание» в отладчике или поиски крупиц полезной информации в логах. Живое воображение с элементами садизма: «а вот мы его еще так попробуем, сверху трейсером придавим, а снизу KD подопрем», берет на себя еще десяток. Чистая удача, хорошая память «где-то я это уже видел» и занудство «а вот почему ту запятая не на месте?» вместе составят – еще десять. Причем на удачу из них приходится ровно 0.42%. Западло, а также строгое выполнение всех законов Мерфи, - и вот еще 9%. На заветное «Эврика! Нашел!» практически ничего не остается. :-(

За последние две-три недели узнал много нового...

Thu, 27 Mar 2008 21:40:52 -0700

За последние две-три недели узнал много нового про архитектуру amd64. Во-первых, я наткнулся сначала на документ, а затем на аналогичный раздел в MSDN, где толково описаны не только соглашения о вызовах (этого добра везде навалом), но и дано детальное описание того, как должен выглядеть стек функции, как происходит раскрутка стека, что такое и зачем нужны пролог и эпилог функции. Полезный документ, особенно если нужно разобраться как работает stack unwinder.

Process Monitor научился трассировать 32-х битный стек на x64

Sun, 23 Mar 2008 22:46:19 -0700

Я как-то привык, что Process Monitor не умеет показывать 32-х битный стек события, которое произошло в 32-х разрядном процессе, выполняющемся под Wow64. Вместо этого он показывал только 64-х битный стек, что было абсолютно бесполезно, так как там по определению всегда светится wow64.dll сотоварищи. Однако после подсказки на Sysinternals Forums выяснилось, что начиная с Vista SP1 это уже работает.

Разрядность ключа «Image File Execution Options»

Wed, 09 Jan 2008 23:34:16 -0800

Ключ «Image File Execution Options» знаком, наверное, всем кто вынужден тратить много времени на отладку приложений. В частности, с его помощью можно указать системе всегда запускать определённый процесс под отладчиком. В этом же ключе утилита gflags.exe сохраняет выбранные отладочные опции и т.д. За подробностями рекомендую обратиться в Google, там есть много полезного.

Как посмотреть содержимое реестра из-под отладчика

Sat, 29 Dec 2007 23:24:18 -0700

_Сижу дома простуженный. Ни о чём писать не хочется, поэтому буду краток. _

Команда !dreg в WinDbg позволяет просматривать содержимое реестра прямо в процессе отладки. Это особенно удобно в двух случаях:

При удалённой отладке, когда сессия отладчика - это единственный вид доступа к удалённой машине. Такое встречается сплошь и рядом, например, если удалённая машина находится в другой сети или домене;
В случае, когда отладчик пользовательского режима контролируется ядерным отладчиком. Это тоже, в общем-то, вариант удалённой отладки, только в этом случае до отлаживаемой машины достучаться кроме как через отладчик вообще никак нельзя.

К сожалению !dreg не работает в ядерном отладчике, вернее работает, но показывает реестр той машины где запущен kd.exe, а не целевой, так бы этого не хотелось. Иначе бы счастье было бы полным.

Говорила мне мама – сынок, проверяй результат каждой вызванной функции!

Thu, 29 Nov 2007 23:03:15 -0700

На днях в очередной раз попробовал поставить Punto Switcher после того, как на глаза попалась заметка о выходе версии, совместимой с Vista. Надо сказать, что я это делаю периодически, - в смысле устанавливаю Punto Switcher, играюсь с ним какое-то время, а потом удаляю. Честно говоря, я и сам не очень понимаю, почему он у меня не приживается. СОвсем неплохо напсаная программа. Какая-то тотальная несправедливость с моей стороны. Хотя нет, в последний раз причина была в том, что он не поддерживает 64-х битные версии Windows.

“4GB will always be enough”

Thu, 18 Oct 2007 21:50:34 -0700

Порой разработчики приложений просто поражают своей храбростью и безудержным оптимизмом. Свежий пример - на днях получаю письмо с просьбой разобраться почему 32-битное приложение, нормально работавшее в Windows Server 2003 for Itanium перестало запускаться в Windows Server 2008 for Itanium. Что особенно приятно, так это то, что вместо традиционного «приложение падает, если сделать то, то и вот то», просто прислали сессию отладчика, остановленную непосредственно перед вызовом NtAllocateVirtualMemory, который и приводил к падению.