Средства QNX6 для диагностики ФПО на объектах применения

advertisement
Средства 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
Download