EnglishУкраїнськаmRussian
Login/New
Topic with many replies

[BugWrong] crash_core c libOPC_UA.cpp


| 1 | 2 | Last
Author Message
Written on: 14. 01. 2014 [11:46]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
Исходные данные
На OpenSCADA используется собственный модуль для сбора данных. Через OPC UA сервер данные предоставляются клиентам.
Были запущены клиенты UAExpert и IWS.
Такая связка проработала не более 4 часов и затем OpenSCADA ушла в crash_core.
С ошибкой
Program terminated with signal 11, Segmentation fault.
#0 OPC::UA::iNu (rb=..., off=@0x7f0675c5429c, vSz=4 '\004') at libOPC_UA.cpp:511
in libOPC_UA.cpp

Файл дампа в приложении.

[This article was edited 1 times, at last 14.01.2014 at 11:48.]
Attachment

crash_core.12115_Boiler_2014-01-13_19:04.txt (File type: text/plain, Size: 36.6 kilobytes) — 1778 downloads
Written on: 14. 01. 2014 [12:08]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3742
"rxs5" wrote:

На OpenSCADA используется собственный модуль для сбора данных. Через OPC UA сервер данные предоставляются клиентам.
Были запущены клиенты UAExpert и IWS.
Такая связка проработала не более 4 часов и затем OpenSCADA ушла в crash_core.
С ошибкой
Program terminated with signal 11, Segmentation fault.
#0 OPC::UA::iNu (rb=..., off=@0x7f0675c5429c, vSz=4 '\004') at libOPC_UA.cpp:511
in libOPC_UA.cpp

Само по себе в этом месте оно падать не может поскольку везде закрыто мютексом, а значит кто-то портит образ памяти параллельно.
Не исключено, что Ваш собственный модуль.
Если ресурсоёмкость (CPU) конфигурации не очень высокая то нужно такое ловить через valgrind.

Как я ранее показывал у меня система проработала 32 часа!

Learn, learn and learn better than work, work and work.
Written on: 14. 01. 2014 [12:24]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
"roman" wrote:

Само по себе в этом месте оно падать не может поскольку везде закрыто мютексом, а значит кто-то портит образ памяти параллельно.
Не исключено, что Ваш собственный модуль.
Если ресурсоёмкость (CPU) конфигурации не очень высокая то нужно такое ловить через valgrind.

Как я ранее показывал у меня система проработала 32 часа!

Роман, помните, что я тоже указывал, что у меня работает стабильно с UAExpert ? Хотя тоже свой модуль используется.
Пока вижу такие предположения.
OpenSCADA OPC UA + UAExpert - работает стабильно.
OpenSCADA OPC UA + UAExpert + IWS - падает, наблюдается точно 2-й раз, возможно 3-й. Да, можно попытаться изолировать до варианта OpenSCADA OPC UA + IWS, но пока не дошел до этого.
Written on: 14. 01. 2014 [12:54]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3742
"rxs5" wrote:

Роман, помните, что я тоже указывал, что у меня работает стабильно с UAExpert ? Хотя тоже свой модуль используется.

Конфигурация OpenSCADA и перечень опрашиваемых параметров тот-же?

"rxs5" wrote:

Пока вижу такие предположения.
OpenSCADA OPC UA + UAExpert - работает стабильно.
OpenSCADA OPC UA + UAExpert + IWS - падает, наблюдается точно 2-й раз, возможно 3-й. Да, можно попытаться изолировать до варианта OpenSCADA OPC UA + IWS, но пока не дошел до этого.

А UAExpert между OpenSCADA и IWS к чему, или они вместе опрашивают?

Вышлите отчёт при следующем падении! Если там кто-то портит память то мала вероятность попадания в тоже место.

Для локализации виновника такой проблемы, кроме варианта с valgrind, можно разделить конфигурацию OpenSCADA на сервер опроса вашим модулем и сервер OPC-UA, с отражением источника данных через DAQGate.

Learn, learn and learn better than work, work and work.
Written on: 14. 01. 2014 [13:23]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
"roman" wrote:

Конфигурация OpenSCADA и перечень опрашиваемых параметров тот-же?

Да, все тоже самое. Проект OpenSCADA настроен и не меняется.

"roman" wrote:

А UAExpert между OpenSCADA и IWS к чему, или они вместе опрашивают?

Вышлите отчёт при следующем падении! Если там кто-то портит память то мала вероятность попадания в тоже место.

Для локализации виновника такой проблемы, кроме варианта с valgrind, можно разделить конфигурацию OpenSCADA на сервер опроса вашим модулем и сервер OPC-UA, с отражением источника данных через DAQGate.

UExpert - является клиентом OPC UA для сервера OPC UA в OpenSCADA
Параллельно работает IWS, который также - является клиентом OPC UA для сервера OPC UA в OpenSCADA.
Запустил недавно на повторный тест.

[This article was edited 1 times, at last 14.01.2014 at 13:24.]
Written on: 14. 01. 2014 [16:43]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
Краха в этот раз не было. Но было зависание OpenSCADA.
Описание условий в сообщении от 14. 01. 2014 [16:33] на странице http://oscada.org/ru/forum/posts//opc_ua//8/
После того, как увидел более 800 сброшенных соединений, перешел на вкладку Debug проекта. И в это время OpenSCADA перестала отвечать.
Во время зависания OpenSCADA у нее было высокое потребление ресурсов, есть скриншоты.
Подождал несколько минут, и убил процесс.
Краш репорта в папке проекта не появилось.

Думаю, что зависание связано с крахом в 1-м сообщении, поскольку в 1-м случае тоже завершался демонстрационный период IWS (и значит увеличивалось число соединений сброшенных по лимиту).
Attachment

Снимок.PNG (File type: image/png, Size: 70.13 kilobytes) — 1812 downloads
Снимок1.PNG (File type: image/png, Size: 35.23 kilobytes) — 1701 downloads
Written on: 14. 01. 2014 [17:30]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3742
"rxs5" wrote:

Во время зависания OpenSCADA у нее было высокое потребление ресурсов, есть скриншоты.

Каких ресурсов?

"rxs5" wrote:

Подождал несколько минут, и убил процесс.
Краш репорта в папке проекта не появилось.

Убивать нужно сигналом SIGSEGV иначе корка просто не создастся!

"rxs5" wrote:

Думаю, что зависание связано с крахом в 1-м сообщении, поскольку в 1-м случае тоже завершался демонстрационный период IWS (и значит увеличивалось число соединений сброшенных по лимиту).

Каким крахом, я там ничего похожего на падение не увидел!

И я просил Вас позакрывать IWS и UAExpert, чтобы выяснить, кто плодит подключения!

Learn, learn and learn better than work, work and work.
Written on: 15. 01. 2014 [16:35]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
"roman" wrote:
Вышлите отчёт при следующем падении!

Еще один отчет во вложении с
Program terminated with signal 11, Segmentation fault.
#0 OPC::UA::iNu (rb=..., off=@0x7f3478df829c, vSz=4 '###Quote_BUFFER_MARKER_MMCMS###4') at libOPC_UA.cpp:511
in libOPC_UA.cpp


"roman" wrote:

Каких ресурсов?

80% CPU, 1,3 Gb Memory. Есть скриншоты в пред. сообщении.
"roman" wrote:
И я просил Вас позакрывать IWS и UAExpert, чтобы выяснить, кто плодит подключения!

Не понял идеи. Если будут закрыты клиенты, то и подключений конечно не будет.

[This article was edited 3 times, at last 15.01.2014 at 16:38.]
Attachment

crash_core.27193_Boiler_2014-01-15_17:30.txt (File type: text/plain, Size: 38.74 kilobytes) — 2200 downloads
Written on: 15. 01. 2014 [18:13]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3742
"rxs5" wrote:

"roman" wrote:
Вышлите отчёт при следующем падении!

Еще один отчет во вложении с
Program terminated with signal 11, Segmentation fault.
#0 OPC::UA::iNu (rb=..., off=@0x7f3478df829c, vSz=4 '###Quote_BUFFER_MARKER_MMCMS###4') at libOPC_UA.cpp:511
in libOPC_UA.cpp


Место падения повторилось, тенденция однако.
Изменил алгоритм удаления элемента в цикле обхода очереди. Хотя это и был принятый оборот, но может для deque он не совсем рабочий.
Кстати на удаление в этом цикле в UAExpert он не попадает поскольку тот всегда их квитирует и они удаляются отдельно.

"rxs5" wrote:

80% CPU, 1,3 Gb Memory. Есть скриншоты в пред. сообщении.

Ничего себе. В модуле OPC_UA течь так нечему.

"rxs5" wrote:

Не понял идеи. Если будут закрыты клиенты, то и подключений конечно не будет.

Вовсе не конечно, а только если потоки обслуживания этих подключений сами внутри не висят.

Learn, learn and learn better than work, work and work.
Written on: 17. 01. 2014 [14:51]
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
"roman" wrote:

Место падения повторилось, тенденция однако.
Изменил алгоритм удаления элемента в цикле обхода очереди. Хотя это и был принятый оборот, но может для deque он не совсем рабочий.
Кстати на удаление в этом цикле в UAExpert он не попадает поскольку тот всегда их квитирует и они удаляются отдельно.


И сегодня снова
Program terminated with signal 11, Segmentation fault.
#0 OPC::UA::iNu (rb=..., off=@0x7f4ac97f929c, vSz=4 '###Quote_BUFFER_MARKER_MMCMS###4') at libOPC_UA.cpp:511
in libOPC_UA.cpp

Файл дампа во вложении.

Кстати, уже второй день, вместо дампов с именем
crash_core.1095_Boiler_2014-01-09_17:37.txt
формируются дампы вида
core.18115_Boiler_2014-01-17_16:28.crash
Это с чем может быть связано ?

Последние строки из консоли:
JAVASCRIPT
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debug*' install /usr/lib/debug/.build-id/63/af03644fcb8724947b123e1677f06ee050a02b
511     libOPC_UA.cpp: No such file or directory.
Core dump process for back trace purchase to file core.20749_Boiler_2014-01-16_17_18.crash_Boiler_2014-01-17_16:28.crash
"/home/Dmitry-L/.openscada/Boiler/core.20749_Boiler_2014-01-16_17_18.crash" is not a core dump: File format not recognized


И еще можно попросить в формате имени файла заменить : например на _ (для совместимости файлов отчета с win системами).

"roman" wrote:

"rxs5" wrote:

Не понял идеи. Если будут закрыты клиенты, то и подключений конечно не будет.

Вовсе не конечно, а только если потоки обслуживания этих подключений сами внутри не висят.

Что видел: сначала было 3 клиента (IWS, UAExpert, контроллер OpenSCADA), затем 2 отключил (IWS, контроллер OpenSCADA), однако в свойствах OPCUA входящего сокета было 2 открытых. Проверял спустя 5-10 минут, хотя должны были закрыться уже 2 из 3.

[This article was edited 6 times, at last 17.01.2014 at 15:17.]
Attachment

core.18115_Boiler_2014-01-17_16_28.crash (File type: application/octet-stream, Size: 36.51 kilobytes) — 1346 downloads
| 1 | 2 | Last



7905