Средства QNX6 для диагностики ФПО на объектах применения Сергей Зыль Использовались материалы компании QNX Software Systems: Malte Mundt, In-Field Debugging: Diagnosing Software Problems While Maintaining System Availability // Embedded World 2009 Проблема диагностики объектового ФПО • Даже качественно разработанное и протестированное ПО содержит ошибки – По данным компании Coverity (http://www.coverity.com) за 2006 год качественное ПО содержит в среднем 434 дефекта на 1 млн. строк исходного текста (в 90-е годы в литературе фигурировала цифра 1 тыс. дефектов на 1 млн. строк. В последнее время «планкой» качества становится значение 290 дефектов на 1 млн. строк кода). • После поставки ПО применение методов поиска дефектов, доступных на этапе разработки, может быть затруднено – Использование функции printf предполагает знание о типе ошибки – Утилиты отображения состояния системы (типа top, ps, pidin) требуют от пользователя интерактивных действий • Необходимо без остановки целевой системы и без создания помех её работе определить «пять W» (WHO, WHAT, WHEN, WHERE, WHY) • Дополнительно требуется устанавливать исправленные компоненты с минимальным временем недоступности сервиса О чём этот доклад • • • • Почему нежелательна модификация ядра? Что такое «крах программы»? «Пять W» диагностики: Who, What, When, Where, Why Установка исправленных компонентов Почему нежелательна модификация ядра? Модифицированное ядро – другое ядро SIL (МЭК 61508) Фактор снижения риска Суммарное время эксплуатации (ч) 4 10 000 – 100 000 3 х 109 3 1 000 – 10 000 3 х 108 2 100 – 1 000 3 х 107 1 10 - 100 3 х 106 34246,58 лет Данные приведены для уровня доверительной вероятности 95% Фактор снижения риска 5000 означает вероятность отказа системы безопасности 0,0002 QNX Software Systems + exida + GE Energy: статистика «Proven-in-Use» по использованию QNX Neutrino на x86 и PowerPC для 6.3.0 и выше (все SP) Лето 2009 – QNX Neutrino используется на 10 млн автомобилей: за 1 год производитель получает 10 млн лет статистики по использованию ядра в разных режимах (ARM, SH-4) Почему нежелательна модификация ядра? Управление сбоями ПО: что даёт микроядерная архитектура QNX – Процессы – Ядро • Полная изоляция • 100% идентификация сбоя • Для восстановления сбившего приложения возможен перезапуск – Включая драйвера, файловые системы и стеки протоколов • Нет изменяемого пользователем кода • Одни и те же двоичные файлы используются во многих системах Почему нежелательна модификация ядра? Размеры исходных текстов ядер (2008 г.) : • WinCE – 3 900 тыс. LOC • Linux – 5 760 тыс. LOC • WinXP – 40 000 тыс. LOC • Neutrino – 100 тыс. LOC О чём этот доклад • • • • Почему нежелательна модификация ядра? Что такое «крах программы»? «Пять W» диагностики: Who, What, When, Where, Why Установка исправленных компонентов Что такое «крах программы»? Что представляет собой выполняющаяся программа, т.е. процесс? • Virtual address space top • • Shared libraries • Objects/Shared memory Heap Сегменты кода и данных исполняемого файла, загруженные в ОЗУ и изолированные от других процессов Контейнер потоков и динамически выделенных ресурсов Информация, зарегистрированная в таблицах ядра и менеджера процессов (pid, ppid, таймеры, префиксы, код завершения и др.) условно - OCB в ресурс-менеджерах 2 threads file descriptors Data Text (Program code) Thread stack 1 Thread stack 2 bottom channel mutex memory Что такое «крах программы»? Завершение процесса • Фаза 1 (собственно уничтожение программы) – Освобождение физически занятых ресурсов (ОЗУ, OCB, таймеры) • Фаза 2 (происходит внутри менеджера процессов) – Очистка таблицы процессов менеджера процессов «Крах программы» - это завершение процесса ядром ОС при нарушении процессом «правил игры» «Крах программы» - штатная ситуация с точки зрения ОС «Крах программы» - по сути положительное явление, обеспечивающее надёжность системы в целом «Крах программы» - это её принудительное завершение менеджером процессов ради сохранения работоспособности всей системы О чём этот доклад • • • • Почему нежелательна модификация ядра? Что такое «крах программы»? «Пять W» диагностики: Who, What, When, Where, Why Установка исправленных компонентов «Пять W» диагностики: Who, What, When, Where, Why Пример информации о крахе программы • «Termination handler» менеджера процессов выдаёт следующую информацию (при запуске procnto с опцией –v): Process 98317 (ResMgr) terminated SIGSEGV code=1 fltno=11 ip=480411a8 ref=00000000 • WHO • WHAT – Process 98317 (ResMgr) • PID и имя процесса, в котором произошёл сбой – Signal= SIGSEGV (попытка нарушения защиты памяти) – fltno= Fault Number в файле /usr/include/sys/fault.h • 11 => FLTPAGE (recoverable page fault) – code = Fault Code в файле /usr/include/sys/siginfo.h • 1 => SEGV_MAPPED : Address not mapped – Попытка доступа к памяти, не отображённой на адресное пространство процесса • ref=00000000 – Попытка обращения по адресу “0” • WHERE – IP (instruction pointer) = 0x480411a8 • Строка кода, которая произвела сбой «Пять W» диагностики: Who, What, When, Where, Why «Where» и «When»: Core-файлы dumper procnto SIGABRT SIGBUS SIGEMT SIGFPE Процесс А core-образ процесса А SIGILL SIGQUIT SIGSEGV SIGSYS SIGTRAP SIGXCPU SIGXFSZ исходный текст Отладчик (gdb) coreinfo «Пять W» диагностики: Who, What, When, Where, Why Анализ core-файла: утилита coreinfo coreinfo /tmp/ResMgr_g.core /tmp/ResMgr_g.core: processor=PPC num_cpus=1 cpu 1 cpu=-2139025388 name=8245 speed=200 flags=0xc0000110 FPU MMU SW_HT cyc/sec=16500000 tod_adj=0 nsec=101631898368 inc=999999 boot=0 epoch=1970 intr=-2147483648 rate=606060606 scale=-16 load=16500 MACHINE="ep8260" HOSTNAME="localhost" pretend_cpu=8454401 init_msr=36866 pid=69645 parent=6 child=0 pgrp=69645 sid=1 flags=0x002210 umask=0 base_addr=0x48040000 init_stack=0x4803fea0 ruid=0 euid=0 suid=0 rgid=0 egid=0 sgid=0 ign=0000000000000000 queue=ff00000000000000 pending=0000000000000000 fds=3 threads=3 timers=0 chans=4 thread 1 ip=0xfe336130 sp=0x47f7cf00 stkbase=0x47f5c000 stksize=135168 state=RECEIVE flags=4020000 last pri=10 realpri=10 policy=RR blocked_chid=1 thread 2 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=0 fltno=11 ip=0x480411a8 sp=0x47fbee50 stkbase=0x47f9e000 stksize=135168 state=STOPPED flags=4020000 last_cpu=1 timeout=00000000 pri=10 realpri=10 policy=RR «Пять W» диагностики: Who, What, When, Where, Why Анализ core-файла: gdb + IDE (Where) Трасса вызовов функций Значения переменных при сбое Строка кода, которая привела к сбою • В стартовой конфигурации «C/C++ Postmortem debugger» «Пять W» диагностики: Who, What, When, Where, Why Инструменты анализа • Системное профилирование (трассировка ядра) – – – – Представляет поведение системы в виде цепочки событий Показывает точное время событий Позволяет находить причинно-следственные связи Отображает взаимодействие между многими потоками и процессами в комплексе • Прикладное профилирование – Анализ использования ЦПУ и выявление «узких» мест • Средства системной информации – Мониторинг создания потоков, использования ресурсов: ЦПУ, ОЗУ, доступ к файлам и т.п. • Трассировка ОЗУ позволяет анализировать утечки, фрагментацию, выделение памяти • Средства кодового покрытия для измерения качества тестов «Пять W» диагностики: Who, What, When, Where, Why Диагностическая информация извлекается из целевой системы в инструментальную IDE Целевая система Ethernet, RS Отображение Перспектива IDE 232, … «Пять W» диагностики: Who, What, When, Where, Why Пример инструментов анализа: системный профилировщик Шкала событий Описание события: время, место, тип и т.д. Монитор использования ЦПУ Анализ данных события ядра «Мгновенный снимок» состояний потоков «Пять W» диагностики: Who, What, When, Where, Why Системное профилирование: When и Why Данные о времени сбоя SIGSEGV Client-2 инициировал транзакцию, которая привела к сбою в модуле ResMgr О чём этот доклад • • • • Почему нежелательна модификация ядра? Что такое «крах программы»? «Пять W» диагностики: Who, What, When, Where, Why Установка исправленных компонентов Восстановление с минимальным временем простоя Монитор ключевых процессов Информация о состоянии в Shared Memory Critical Process Monitor (CPM) CPM Guardian Application A Driver Application B Driver Microkernel 1. Сбой драйвера (некорректный доступ к памяти) 2. Ядро извещает CPM о сбое процесса 3. Сохраняется диагностическая информация (core-файл и kev-файл) 4. Драйвер завершается возвращает системе ресурсы; канал IPC разрушен 5. CPM перезапускает драйвер 6. Клиентская библиотека CPM восстанавливает каналы IPC 7. Драйвер запрашивает информацию о состоянии в последней точке синхронизации (checkpoint) из CPM и восстанавливает сервис Восстановление с минимальным временем простоя • • Использование квотирования Резервирование небольшого количества ресурсов ЦПУ, чтоЦПУ бы позволить при необходимости выполняться отладочным сессиям Гарантирует, что выполнение диагностических процедур не повлияет на способность системы выполнять свои задачи Установка исправленных компонентов Установка исправлений – Скопировать новый драйвер или приложение на целевую систему – Остановить (выгрузить) старый драйвер; запустить (смонтировать) и сконфигурировать новый драйвер – Вариант действий при использовании CPM • Послать процессу сигнал SIGTERM для завершения • HAM обнаружит завершение процесса и выполнит все необходимые шаги, но используя новый двоичный модуль Выводы • Ядро QNX Neutrino имеет малый размер и тщательно протестировано • Ядро QNX Neutrino не требует изменений при изменении состава драйверов и механизмов ОС • ОСРВ QNX Neutrino имеет штатные механизмы для обеспечения сбора необходимой диагностической информации • ОСРВ QNX Neutrino имеет штатные механизмы для обеспечения безболезненного внесения исправлений в объектовое ПО Спасибо за внимание! Прошу задавать вопросы Сергей Зыль www.kpda.ru | forum.kpda.ru ООО «СВД Встраиваемые Системы» Административный офис: 196066, г. Санкт-Петербург, Московский проспект, д. 212 А Технический офис: 191014, г. Санкт-Петербург, ул. Госпитальная, д.3 тел.: (812) 373-41-17 факс: (812) 373-19-07 e-mail: sales@kpda.ru тел./факс: (812) 578-02-45 e-mail: support@kpda.ru