Документи/Як/Звітувати про аварійне завершення

• Автор: Роман Савоченко

Налагодженню та тестуванню OpenSCADA приділяється значний час розробників, однак у зв'язку із обмеженістю ресурсів і практичною неможливістю охопити всі варіанти конфігурації та виконання OpenSCADA, помилки можуть проявлятися як у вигляді невиконання окремих функцій, некоректності їх виконання та навіть аварійного завершення програми у користувачів. Розуміння цього з боку користувача дуже важливе та від нього потребується добра воля і деякий час на приготування звіту про проблему, з метою її наступного усунення розробниками.

1 Умови та варіанти звітування

Повідомити про помилку у програмі може кожен, для її розгляду розробниками на загальних підставах вільної технічної підтримки, поза угодою комерційної технічної підтримки або виконання робіт цього користувача. Але будуть розглянуті розробниками тільки помилки, що є помилками безпосередньо OpenSCADA, не є проблемами оточення та сторонніх бібліотек, відтворюються у розробника на демонстраційних конфігураціях останніх версій OpenSCADA та наявному обладнані проекту OpenSCADA!

Основним і єдиним офіційним місцем повідомлення про помилки на загальних підставах вільної технічної підтримки є розділ форуму "Відстеження помилок", де розробники гарантовано дадуть на нього відповідь. Якщо Ви не певні, що це помилка безпосередньо OpenSCADA, тоді краще напишіть повідомлення про неї у інший розділ форум OpenSCADA, де ніяких гарантій відповіді не надається. Інакше, після трьох поспіль некоректних повідомлень про помилку, Вас буде відключено від форуму за злісне отримання технічної підтримки та консультації, безплідно витрачаючи таким чином час розробників! Правила повідомлення про помилки детально викладено тут.

Перед формуванням звіту про помилку на загальних підставах вільної технічної підтримки, треба на сторінці міток форуму ознайомитися з переліком відомих помилок:

• підтверджених-відкритих та вирішуваних наразі — "BugConfirmed";
• що наразі потребують зворотнього зв'язку від автора — "BugNeedFeedBack";
• оточення виконання та специфічні до користувача — "BugEnvironment";
• некоректних повідомлень про помилку — "BugWrong".

Повідомлення про помилки у програмі на підставі комерційної технічної підтримки або виконання робіт користувача, можна здійснити у такі способи, згідно до пріоритету розробника:

• у розділі форуму "Технічна підтримка", який з'являється та доступний для зареєстрованих користувачів, що мають активний пакет технічної підтримки;
• електронною поштою на адресу service at oscada.org;
• безпосередньо електронною поштою, сервісом миттєвих повідомлень та дзвінків, або телефоном розробника, а також приватним повідомленням форуму (для зареєстрованих користувачів).

2 Requirements for the error report

In order to exclude unnecessary overhead questions, or even premature closure of the error in the state "Not a bug", and to speed up the process of localization of the problem, it is recommended to follow the following requirements for the report:

• Specify the environment of the execution of OpenSCADA, that is: distribution and version of the operating system.
• Specify the version of OpenSCADA, including the SVN revision of the working branch.
• Specify the configuration and execution features.

In the case of free support, it is mandatory to reproduce the problem in standard configurations and in the demo database, especially when it is an emergency crash and it is not possible to generate a crash report or it is indescribable.

• Describe the actions that cause the error.
• Attach the OpenSCADA message protocol for a session with the error.
• Include report of the program crash — unroll the stack at the time of the crash.
  • the report is usually generated automatically by generating it from the crashing process or pre-mortem memory dump (earlier) — just install GDB; refer to the next section for some specific here;
  • to increase significantly the use of the stack unrolling, you must add debugging information, by setting the "-g" option during compilation, or install the ready debug package openscada-dbg;
  • for problems, related to the blocking of one or more OpenSCADA threads, it may be useful to manually interrupt the program by call openscada-proj snapshot {ProjID} or the "SIGSEGV" signal, which will cause the formation of the fall-down report with the information about the hangover.

3 Отримання файлу передсмертного дампу та його обробка (ЗАСТАРІЛЕ)

Секція наразі неактуальна для нових версій OpenSCADA, але можете використати її вміст для старих версій або у специфічному і ручному вивчені аварійних завершень!

Під час аварійного завершення програми ядро ОС Linux може формувати передсмертний дамп пам'яті програми. За допомогою цього дампу часто можна виявити місце у програмі, яке викликало аварійну зупинку. Для включення можливості генерації ядром Linux передсмертного дампу пам'яті програми потрібно виконати команди:

# Перевірка можливості генерації дампів пам'яті
# Повертає "core", якщо включена
cat /proc/sys/kernel/core_pattern
# Включення генерації дампів пам'яті
echo "core" > /proc/sys/kernel/core_pattern

Після цього потрібно зняти обмеження на розмір генерованого файлу дампу. Це обмеження, по замовченню, у OpenSCADA знято та встановлюється воно аргументом командного рядку --noCoreDump. Зняти це обмеження, на рівні операційної системи, можна виконавши, перед викликом OpenSCADA, спеціальну команду ulimit -c unlimited.

Потім треба переконатися у тому, що користувач, який запускає OpenSCADA, має право запису до робочої теки OpenSCADA, що у останніх версіях OpenSCADA є обов'язковим та забезпечується менеджером проектів OpenSCADA.

Далі запускається OpenSCADA та відтворюється аварійне завершення, у результаті якого, у робочій теці OpenSCADA, створюється файл "core".

Останні версії OpenSCADA забезпечують автоматичну генерацію звіту про аварійне завершення, за наявності файлу передсмертного дампу "core" та налагоджувача gdb, та це здійснюється на початку запуску OpenSCADA. Файли звітів про аварійне завершення отримують назву виду "AGLKS_core_2018-02-16_22.06.crash" та накопичуються у робочій теці відповідного проекту OpenSCADA.

Якщо файл дампу пам'яті "core" сформувався, а звіт про аварійне завершення автоматично не генерується, то ймовірно не встановлено налагоджувача gdb. У такому випадку Ви маєте його встановити та викликати:

• сервісну процедуру менеджеру проектів OpenSCADA:

openscada-proj proc {ProjName}

• або команду прямого виклику налагоджувача, із робочої теки проекту:

gdb openscada --core core --batch --quiet -ex "thread apply all bt full" -ex "quit" > {ProjName}_core_$(date +%F_%H:%M).crash

• або пряму процедуру налагоджувача у інтерактивному режимі, через виклик gdb без аргументів:

# Перехід до робочої теки проекту OpenSCADA
(gdb) cd /var/spool/openscada/{ProjName}
(gdb) cd ~/.openscada/{ProjName}
# Вказання виконувального файлу
(gdb) file /usr/bin/openscada
# Вказання файлу дампу пам'яті програми
(gdb) core-file ./core.26658
# Отримання розвороту стеку виконання — звіту про аварійне завершення
(gdb) thread apply all bt full
#0  0xb7d104c0 in pthread_cancel () from /lib/librt.so.1
#1  0xb7d1edaa in start_thread () from /lib/libpthread.so.0
#2  0xb7dfcf5e in clone () from /lib/libc.so.6