?

Log in

Pygdb - A cure for !being an axe-wielding homicidal maniac [entries|archive|friends|userinfo]
A cure for !being an axe-wielding homicidal maniac

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Pygdb [сент. 24, 2008|02:34 am]
A cure for !being an axe-wielding homicidal maniac
GDB when the program's wrong and the debug's on
It's GDB when the system dies and you don't know why
It's hard to bear
With no one to help you
You're going nowhere
GDB when you press control and the box just rolls
It's GDB when the system dies and you don't know why
It's hard to bear
With no one beside you
You're going nowhere


Gdb это очень мощный отладчик, используемый в основном в Linux/Unix. Gdb — консольный отладчик, т.е. он принимает команды из терминала и выводит ответ туда же. Если перенаправить ввод-вывод, то можно генерировать команды для gdb скриптом, и автоматически анализировать ответ gdb. Это открывает много интересных возможностей!

Вывод gdb достаточно просто парсить (опции --annotate, --interpreter). В процессе написания собственного велосипеда, я наткнулся на очень удобную библиотеку, pygdb. Библиотека предоставляет класс Gdb. Каждой команде gdb соответствует метод этого класса; почти все они реализованы.

Зачем может потребоваться скриптовать gdb?

Есть такая задача. Необходимо протестировать recovery в СУБД Sedna — убедиться что сбои не приводят к потере данных. Делается это так — в коде выделяется ряд критичных функций. Тестовая система выполняет поток запросов; когда поток выполнения попадает в критичную функцию, бросается кубик. Если выпавшее случайное число превышает установленный порог, инициируется аварийное завершение процесса СУБД. Затем делается попытка снова поднять базу, и провести recovery. Тест продолжается до тех пор, пока не будет достигнуто покрытие всех критичных функций — т.е. в каждой из функций было хотя бы одно падение.

Задачу предлагается решать следующим образом. Процесс СУБД запускается под отладчиком.
Отладчик управляется скриптом. Скрипт ставит брейкпоинты во всех критичных функциях. Как только процесс СУБД останавливается на брейкпоинте, скрипт анализирует имя текущей функции, принимает решение падать или не падать, и обновляет данные о полноте тестового покрытия.

Условия на падение можно сделать очень продвинутыми. Из gdb мы извлекаем информацию о стеке. Условие может выглядеть так — упасть в функции foo с вероятностью 30%, но не ранее 100-ого вызова функции foo, и только если она была вызвана из функции bar.
СсылкаОтветить