Difference between revisions of "Documents/How to/Crash report/uk"

Latest revision as of 23:08, 6 December 2024

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

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

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

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

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

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

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

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

2 Вимоги до звіту про помилку

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

• Вказати оточення виконання OpenSCADA, а саме: дистрибутив та версію операційної системи.
• Вказати версію OpenSCADA, включаючи SVN-ревізію робочої гілки.
• Вказати особливості конфігурації та виконання.

У випадку вільної підтримки обов'язковим є відтворення проблеми у стандартних конфігураціях та на демонстраційній БД, особливо якщо це аварійне завершення програми та неможливо сформувати звіт про падіння або він виявляється непоказовим.

• Описати дії, які викликають помилку.
• Вкласти протокол повідомлень OpenSCADA для сеансу з відтворенням помилки.
• Вкласти звіт аварійного завершення програми — розворот стеку виконання на момент аварійного завершення.
  • звіт зазвичай формується автоматично, генерацією із процесу, що падає або передсмертного дампу пам'яті (раніше) — просто встановіть GDB; щодо специфіки тут читайте у наступному розділі;
  • для значного збільшення користі розвороту стеку маєте додати налагоджувальну інформацію, встановленням опції "-g" під час компіляції, або встановити готовий налагоджувальний пакет openscada-dbg;
  • при проблемах, пов'язаних із зависанням-блокуванням однієї або декількох задач-потоків OpenSCADA, для їх локалізації може бути корисним ручне переривання програми openscada-proj snapshot {ProjID} або сигналом "SIGSEGV", що викличе формування звіту про падіння з інформацією про місце зависання.

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