- Автор: Роман Савоченко
Отладке и тестированию OpenSCADA уделяется значительное время разработчиков, однако в виду ограниченности ресурсов и практической невозможности охватить все варианты конфигурации и исполнения OpenSCADA, ошибки могут проявляться как в виде невыполнения отдельных функций, некорректности их выполнения и даже аварийного завершения программы у пользователей. Понимание этого со стороны пользователя очень важно и от него требуется добрая воля и некоторое время на подготовку отчёта о проблеме, с целью её последующего устранения разработчиками.
Contents
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 Obtaining the file of the pre-mortem dump and its processing (DEPRECATED)
The section is not actual more for new versions of OpenSCADA, but you can use its content for old versions or in specific and manual learning the crashes!
Во время аварийного завершения программы ядро ОС 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