This page is frozen,

Guide to localize crashes and to report about them

Introduction

For debugging and system testing of OpenSCADA it is given considerable time of developers, but in view of limited resources and even a practical impossibility to cover all the configuration options and performance of OpenSCADA system, errors can occur either as a failure of some functions, incorrectness of their implementation and even crash of the program. Understanding of this from the user side is very important, and with his hand it is required goodwill to cost some time to prepare a report on the problem with a view of its subsequent removal by developers.

Before preparing the report of the problem it is recommend to review the list of errors and comments in the corresponding part Errors and comments to OpenSCADA system.

Requirements for the report of an error

To avoid unnecessary suggestive questions and to accelerate the localization of the problem it is recommended to follow the requirements for report.

To specify the execution environment of OpenSCADA, that is the distribution and version of operating system.
To specify the version of OpenSCADA system, include SVN-revision for Work versions.
To specify the particular features of the configuration and execution. It is desirable to achieve the demonstration of the problem in standard configurations and on the demonstration database. If this can not be achieved, it is necessary to describe the particular configuration and to attach to the report the database, in which the problem takes place.
Describe the actions causing the error.
To attach the report of OpenSCADA messages for the session with the error.
In the case of crash it is necessary to form a file of pre-mortem dump of the program and get out from him the back trach of the stack of execution at the time of the crash. At problems, which caused by hung one or more OpenSCADA tasks, manual termination by signal "SIGSEGV" for localisation can be useful, that cause forming pre-morten dump with information about hung place.
To increase significant usability of the back trace you need append debug information by option "-g" set in compile or install ready debug packages.

Variants of the report

To report about an error in the OpenSCADA system it is possible in several ways:

in the appropriate forum section of the official site: http://oscada.org/en/forum ;
by e-mail address oscada@oscada.org or developers addresses;
in the part Errors and comments to the OpenSCADA system in the knowledge base of the project.

Getting the pre-mortem dump file and its processing

In the Linux operating system while crashing of programs the OS kernel can generate the pre-mortem memory dump of the program. With this dump it is often possible to identify a place in the program that caused the emergency stop. To enable the generation of pre-mortem memory dump of the program by the kernel it is necessary to execute the following commands:


# Check the possibility of generation of memory dumps
# Specifies the "core" if it is enabled
$ cat /proc/sys/kernel/core_pattern
# Enabling the generation of memory dumps
$ echo "core" > /proc/sys/kernel/core_pattern

After this you should remove the restriction on the size of the generated dump file, which can run from OpenSCADA argument --CoreDumpAllow or run a special command before calling OpenSCADA "$ ulimit-c unlimited".

Next you can just make sure that the user which running OpenSCADA, is entitled to write in the working directory OpenSCADA, parameter "Workdir" in the configuration file of the program.

Then the OpenSCADA system is running and the crashe is reproduced, the result of which the file is created in a working directory of the OpenSCADA core.

Typical startup scripts OpenSCADA, which come in packages OpenSCADA distributions from version 0.8.0 include the generation of memory dump file and automatically generate a report of the backtrace as files "AGLKS_core_2016-03-20_18.17.crash" (for 0.9 Work) or "crash_2012-01-05_11:05.txt" (for 0.8 LTS) in the working directory of the project.

If created the file memory dump core, and a report of backtrace is not automatically generated, you probably do not have a debugger "gdb". In this case, you need to install it and manually invoke the command from work directory for the global configuration:

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

Or do the same procedure in an interactive mode to global configuration:


# Transfer to the working directory of OpenSCADA
(gdb) cd /var/spool/openscada
# Specifying an executable file, not scripts!
(gdb) file /usr/bin/openscada
# Specifying the dump file of the program
(gdb) core-file /var/spool/openscada/core.26658
# Getting the reversal of the stack execution
(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