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

Home | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
 

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.

Variants of the report

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

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


 
Один файл.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]