DTV-TraceInt

1. DTV-TraceInt Система отладки и анализа исполнения программ на основе отладочной трассы Иночкин Федор fedor.inochkin@gmail.com 2011

2. Отладка в жизни программиста • этап разработки, на котором обнаруживают, локализуют и устраняют ошибки • обнаружение причины ошибки • в процессе: • непосредственной разработки (кодирование) • тестирования (модуля, системы) • 90-30% времени разработки (~жизни) • Зависит от используемых инструментов

3. Типы ошибок 1 • Логические if (!flag) printf(“flag is set”); • «Не по спецификации» (неверное использование) • Кто виноват? • Синхронизации (динамика процессов) • Deadlock • Низкая производительность

4. Типы ошибок 2 • Устойчивые • Исправляются после первого прогона программы по пути с ошибкой • Неустойчивые («гейзенбаги») • Появляются при сдаче программы в присутствии заказчика • 50/50 или 0,01%

5. 2 (+1) стратегии отладки • «Breakpoint» • Пошаговое исполнение • Останов по заданному условию (ASSERT(1==2), *NULL=42, x/=0, …) • Останов при выполнении заданного оператора • «Trace» • Журналирование событий • Вывод значений переменных • Статистический анализ • Анализ времени исполнения участков программы • Анализ утечек памяти

6. 2 стратегии отладки (+-) • «Breakpoint» • (+) Позволяет просмотреть значение переменных к заданному моменту времени • Позволяет проследить путь программы после возникновения breakpoint в интерактивном режиме • Только частичная информация о пути до возникновения breakpoint (call stack) • (-) Нарушается real-time • (-) Ничего не сообщает о взаимодействии процессов • «Trace» • (+) Полная информация о пути (в случае наличия достаточно подробной трассы) – до и после возникновения ошибочной ситуации • (+) взаимодействие процессов • (+) не нарушает real-time • (-) требуется поиск участка трассы, относящегося к ошибочной ситуации (!) • Обычно сложно работать с многопоточными системами (перемешивание сообщений) • (-) нельзя узнать состояния переменных, которые не были включены в трассу • (+) читаемость программы (вывод информативных сообщений = комментарий) • (+) командная работа, обмен результатами в процессе отладки

7. Инструменты отладки • «Breakpoint» • MSVS, GDB, …, …, … • «Trace» • Консоль (printf) • Файл (log, syslog) • «Внешняя» консоль (DbgView) • Перехват системных вызовов (ETW, DTrace) • Анализ трафика (сниферы), перехват запросов (SQL) • Мониторы ресурсов (устройства, файлы, объекты ядра) • Статистический анализ • TraceView (Android) • MSVS, GDB, …

8. Инструменты отладки - trace • «Trace» • Консоль (printf) • Файл (log, syslog) • «Внешняя» консоль (DbgView) • Перехват системных вызовов (ETW, DTrace) • Анализ трафика (сниферы), перехват запросов (SQL) • Мониторы ресурсов (устройства, файлы, объекты ядра) Трудно осуществить поиск нужного участка трассы Только взгляд «извне»

9. DTV-TraceInt • DTV – пользовательский интерфейс • Захват трассы • Эффективное представление трассы • Интерактивная локализация интересующих участков трассы • Средства статистического анализа • TraceInt • Библиотека вывода отладочных сообщений • Набор макросов printf-стиля • TRACE_INFO, TRACE_ERROR, TRACE_WARNING, TRACE_CALL, …

10. DTV

11. TraceInt class CTraceTestClass { public: CTraceTestClass() { TRACE_CALL; } ~CTraceTestClass() { TRACE_CALL; } void do_smth() { TRACE_CALL; TRACE_INFO("Doing something..."); } }; Варианты подключения: -DLL -Статически

12. DTV • Каждое сообщение трассы состоит из полей: • номер • метка времени • id процесса • имя модуля • id потока • уровень вложенности • тип • контекст (идентификатор экземпляра объекта, от которого исходит сообщение) • текст сообщения • Выборка «двойным щелчком» • Сообщения от процесса, модуля, потока, объекта, … • Текущая функция • Фильтры сообщений • Call stack • Профилировщик • Работа в команде - обмен файлами .dt

13. DTV - настройка • Фильтры отображения • Список «захватываемых» модулей • Увеличение производительности системы за счет исключения некоторых модулей • Обычно модуль=exe/dll, но может быть класс или даже часть класса • Предел около 40000 сбщ/с

14. DTV-TraceInt – когда не следует использовать? • Для отладки алгоритмов обработки данных с большим числом итераций (внутри цикла) • Предел 40000 сбщ/с • В «конечных» версиях закрытых программ • Проблема обратного инжиниринга (на основе текста отладочных сообщений) • TRACE_OFF

15. DTV-TraceInt - развитие • Отображение timeline и MSC-диаграмм • Обработка сложных типов данных (изображения, массивы, …) • Портирование под Linux • Протокол и traceint • Внедрение в Python, Java • Разработка средств для отладки встраиваемых систем

16. Ссылки https://bitbucket.org/Fedek239/traceint_public Сборка в Downloads. Репозиторий с исходным кодом – hg. Readme в каталоге readme и на странице Wiki. В readme рассказано о том, как подключить библиотеку, как ее использовать и как решить ряд стандартных проблем, связанных с использованием. Комментарии можно оставить в Issues. https://bitbucket.org/Fedek239/dtv_public Сборка в Downloads. User Manual в архиве. Комментарии можно оставить в Issues.

17. Заключение… «Наш личный выбор — стараться не использовать отладчики, кроме как для просмотра стека вызовов или же значений пары переменных. Одна из причин этого заключается в том, что очень легко потеряться в деталях сложных структур данных и путей исполнения программы. Мы считаем пошаговый проход по программе менее продуктивным, чем усиленные размышления и код, проверяющий сам себя в критических точках. Щёлканье по операторам занимает больше времени, чем просмотр сообщений операторов выдачи отладочной информации, расставленных в критических точках. Быстрее решить, куда поместить оператор отладочной выдачи, чем проходить шаг за шагом критические участки кода, даже предполагая, что мы знаем, где находятся такие участки. Более важно то, что отладочные операторы сохраняются в программе, а сессии отладчика переходящи. … «Отладка сложна и может занимать непредсказуемо долгое время, поэтому цель в том, чтобы миновать большую её часть. Технические приёмы, которые помогут уменьшить время отладки, включают хороший дизайн, хороший стиль, проверку граничных условий, проверку правильности исходных утверждений и разумности кода, защитное программирование, хорошо разработанные интерфейсы, ограниченное использование глобальных переменных, автоматические средства контроля и проверки. Грамм профилактики стоит тонны лечения.» — Брайан Керниган и Роб Пайк