OpenSCADAWiki: Home Page Uk/Doc/ Crash Report ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
English (1 Кб) English
Russian (1 Кб) Российский
 (2 Кб) Сторінку заморожено, актуальна тут.

Посібник по локалізації збоїв та приготування звітів про них

Вступ

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


Перед приготуванням повідомлення про проблему рекомендується ознайомитися з переліком помилок та зауважень у відповідному розділі Помилки та зауваження до системи OpenSCADA.

Вимоги до повідомлення про помилку

Для виключення зайвих навідних питань та для прискорення процесу локалізації проблеми рекомендується слідувати наступним вимогам до повідомлення.

Способи повідомлення

Повідомити про помилку у системі OpenSCADA можна декількома способами:

Отримання файлу передсмертного дампу та його обробка

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

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


Після цього потрібно зняти обмеження на розмір генерованого файлу дампу, для чого OpenSCADA можна запустити з аргументом --CoreDumpAllow або виконати спеціальну команду перед викликом OpenSCADA "$ ulimit -c unlimited".


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


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


Типові скрипти запуску OpenSCADA, які постачаються у пакетах дистрибутивів OpenSCADA з версії 0.8.0, включають генерацію дампу пам'яті та автоматично формують з нього звіт зворотніх викликів (backtrace) у вигляді файлів "AGLKS_core_2016-03-20_18.17.crash" (для 0.9 Work) або "crash_2012-01-05_11:05.txt" (для 0.8 LTS) у робочій директорії проекту.


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

$ gdb openscada --core core --batch --quiet -ex "thread apply all bt full" -ex "quit" > crash_$(date +%F_%H:%M).txt

Або-ж виконати процедуру у інтерактивному режимі, для глобальної конфігурації:

# Перехід до робочої директорії OpenSCADA
(gdb) cd /var/spool/openscada
# Вказання виконувального файлу, не скрипти!
(gdb) file /usr/bin/openscada
# Вказання файлу дампу пам'яті програми
(gdb) core-file /var/spool/openscada/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


 
There are no files on this page.[Display files/form]
There is no comment on this page. [Display comments/form]