[BugWrong]
crash_core c libOPC_UA.cpp
| Автор |
Повідомлення |
|
Повідомлення створено: 14. 01. 2014 [11:46]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 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
Файл дампа в приложении.
[Повідомлення редагувалось 1 раз(ів), останній раз 14.01.2014 в 11:48.]
Вкладений файл
|
|
Повідомлення створено: 14. 01. 2014 [12:08]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"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.
|
|
Повідомлення створено: 14. 01. 2014 [12:24]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 205
|
"roman" wrote:
Само по себе в этом месте оно падать не может поскольку везде закрыто мютексом, а значит кто-то портит образ памяти параллельно.
Не исключено, что Ваш собственный модуль.
Если ресурсоёмкость (CPU) конфигурации не очень высокая то нужно такое ловить через valgrind.
Как я ранее показывал у меня система проработала 32 часа!
Роман, помните, что я тоже указывал, что у меня работает стабильно с UAExpert ? Хотя тоже свой модуль используется.
Пока вижу такие предположения.
OpenSCADA OPC UA + UAExpert - работает стабильно.
OpenSCADA OPC UA + UAExpert + IWS - падает, наблюдается точно 2-й раз, возможно 3-й. Да, можно попытаться изолировать до варианта OpenSCADA OPC UA + IWS, но пока не дошел до этого.
|
|
Повідомлення створено: 14. 01. 2014 [12:54]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"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.
|
|
Повідомлення створено: 14. 01. 2014 [13:23]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 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.
Запустил недавно на повторный тест.
[Повідомлення редагувалось 1 раз(ів), останній раз 14.01.2014 в 13:24.]
|
|
Повідомлення створено: 14. 01. 2014 [16:43]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 205
|
Краха в этот раз не было. Но было зависание OpenSCADA.
Описание условий в сообщении от 14. 01. 2014 [16:33] на странице http://oscada.org/ru/forum/posts//opc_ua//8/
После того, как увидел более 800 сброшенных соединений, перешел на вкладку Debug проекта. И в это время OpenSCADA перестала отвечать.
Во время зависания OpenSCADA у нее было высокое потребление ресурсов, есть скриншоты.
Подождал несколько минут, и убил процесс.
Краш репорта в папке проекта не появилось.
Думаю, что зависание связано с крахом в 1-м сообщении, поскольку в 1-м случае тоже завершался демонстрационный период IWS (и значит увеличивалось число соединений сброшенных по лимиту).
Вкладений файл
Снимок.PNG (Тип файлу: image/png, Розмір: 70.13 кілобайтів) — 1957 завантажень
Снимок1.PNG (Тип файлу: image/png, Розмір: 35.23 кілобайтів) — 1848 завантажень
|
|
Повідомлення створено: 14. 01. 2014 [17:30]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"rxs5" wrote:
Во время зависания OpenSCADA у нее было высокое потребление ресурсов, есть скриншоты.
Каких ресурсов?
"rxs5" wrote:
Подождал несколько минут, и убил процесс.
Краш репорта в папке проекта не появилось.
Убивать нужно сигналом SIGSEGV иначе корка просто не создастся!
"rxs5" wrote:
Думаю, что зависание связано с крахом в 1-м сообщении, поскольку в 1-м случае тоже завершался демонстрационный период IWS (и значит увеличивалось число соединений сброшенных по лимиту).
Каким крахом, я там ничего похожего на падение не увидел!
И я просил Вас позакрывать IWS и UAExpert, чтобы выяснить, кто плодит подключения!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 15. 01. 2014 [16:35]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 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, чтобы выяснить, кто плодит подключения!
Не понял идеи. Если будут закрыты клиенты, то и подключений конечно не будет.
[Повідомлення редагувалось 3 раз(ів), останній раз 15.01.2014 в 16:38.]
Вкладений файл
|
|
Повідомлення створено: 15. 01. 2014 [18:13]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"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.
|
|
Повідомлення створено: 17. 01. 2014 [14:51]
|
|
rxs5
Дмитрий Лыков
In tech support
Автор теми
Зареєстрован(а) с: 06.11.2013
Повідомлення: 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
Это с чем может быть связано ?
Последние строки из консоли:
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.
[Повідомлення редагувалось 6 раз(ів), останній раз 17.01.2014 в 15:17.]
Вкладений файл
|
|
|
