Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault after execution state command/attribute, at check_level_alarm #330

aleolivo opened this issue Dec 12, 2016 · 1 comment


Copy link

commented Dec 12, 2016

Using Tango 9.2.2 (with omniORB-4.2.1 and with zermq-4.0.7):
A segmentation fault occurred after the state command/attribute execution, by client (tested with Jive or AtkPanel), if the alarm threshold on one or more attributes is configured and if an exception is thrown during the "read" method of an attribute.

I did this simple testing device server (threshold-srv) to point out the segmentation fault. It has two commands: "On" and "Off" in order to change the device state and has two attributes: AttrUShort (DevUShort) and ActivateException (DevBoolean). I configured an alarm threshold on the first attribute and when the second attribute is set to "true" it makes the read_AttrUShort() throw an exception.
To test the crash launch the AtkPanel, excecute "On" command and check the ActivateException checkbox.

Tests done :

  • It crashes even if I configure the threshold at runtime time in tango db;
  • It crashes if compiled with Tango-9.2.2 without p922_1 patch and with Tango-9.1.0 (with omniORB-4.2.0 and with zermq-4.0.5);
  • It crashes with every type of numeric attributes;
  • It doesn't crash with tango 8.1.2 (with omniORB-4.1.6 and with zermq-4.), when the exception is thrown by the read_ the client show the exception;
  • activating Polling works around the problem

Debugger :

  • The error:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2c87b70 (LWP 5392)]
0xb7b374b7 in Tango::Attribute::check_level_alarm (this=0x8099688) at ../../../../lib/cpp/server/attribute.cpp:1898
1898 if ((*value.ush_seq)[i] <= min_alarm.ush)

  • Back trace:

#0 0xb7b374b7 in Tango::Attribute::check_level_alarm (this=0x8099688) at ../../../../lib/cpp/server/attribute.cpp:1898
#1 0xb7b36efb in Tango::Attribute::check_alarm (this=0x8099688) at ../../../../lib/cpp/server/attribute.cpp:1703
#2 0xb7c33e4a in Tango::MultiAttribute::check_alarm (this=0x8096fd8, ind=0) at ../../../../lib/cpp/server/multiattribute.h:221
#3 0xb7c31de9 in Tango::MultiAttribute::check_alarm (this=0x8096fd8) at ../../../../lib/cpp/server/multiattribute.cpp:1204
#4 0xb7b78cdf in Tango::DeviceImpl::dev_state (this=0x80970d0) at ../../../../lib/cpp/server/device.cpp:1230
#5 0xb7b4f551 in Tango::DevStateCmd::execute (this=0x8096ca8, device=0x80970d0, in_any=...) at ../../../../lib/cpp/server/basiccommand.cpp:167
#6 0xb7bc6a57 in Tango::DeviceClass::command_handler (this=0x8096b58, device=0x80970d0, command=..., in_any=...)
at ../../../../lib/cpp/server/deviceclass.cpp:1172
#7 0xb7b79692 in Tango::DeviceImpl::command_inout (this=0x80970d0, in_cmd=0x80bbae0 "State", in_any=...) at ../../../../lib/cpp/server/device.cpp:1442
#8 0xb7b96edb in Tango::Device_2Impl::command_inout_2 (this=0x80970d0, in_cmd=0x80bbae0 "State", in_data=..., source=Tango::CACHE_DEV)
at ../../../../lib/cpp/server/device_2.cpp:440
#9 0xb7bb3cad in Tango::Device_4Impl::command_inout_4 (this=0x80970d0, in_cmd=0x80bbae0 "State", in_data=..., source=Tango::CACHE_DEV, cl_id=...)
at ../../../../lib/cpp/server/device_4.cpp:475
#10 0xb7da1d63 in _0RL_lcfn_6fe2f94a21a10053_a3000000 (cd=0xb2c86dd4, svnt=0x809750c) at tangoSK.cpp:5383
#11 0xb7531748 in omniCallHandle::upcall(omniServant*, omniCallDescriptor&) () from /usr/local/omniorb-4.2.1/lib/
#12 0xb7da3990 in Tango::_impl_Device_4::_dispatch (this=0x8097508, _handle=...) at tangoSK.cpp:5958
#13 0xb7da8804 in Tango::_impl_Device_5::_dispatch (this=0x8097508, _handle=...) at tangoSK.cpp:7478
#14 0xb751c57a in omni::omniOrbPOA::dispatch(omniCallHandle&, omniLocalIdentity*) () from /usr/local/omniorb-4.2.1/lib/
#15 0xb74fa916 in omniLocalIdentity::dispatch(omniCallHandle&) () from /usr/local/omniorb-4.2.1/lib/
#16 0xb7557bc1 in omni::GIOP_S::handleRequest() () from /usr/local/omniorb-4.2.1/lib/
#17 0xb75599f5 in omni::GIOP_S::dispatcher() () from /usr/local/omniorb-4.2.1/lib/
#18 0xb7554b97 in omni::giopWorker::execute() () from /usr/local/omniorb-4.2.1/lib/
#19 0xb74efb5d in omniAsyncWorker::real_run() () from /usr/local/omniorb-4.2.1/lib/
#20 0xb74effcb in omniServerWorkerInfo::run() () from /usr/local/omniorb-4.2.1/lib/
#21 0xb74f10da in omniAsyncPoolServer::workerRun(omniAsyncWorker*) () from /usr/local/omniorb-4.2.1/lib/
#22 0xb74f04cb in omniAsyncWorker::mid_run() () from /usr/local/omniorb-4.2.1/lib/
#23 0xb74f07cb in omniAsyncWorkerInfo::run() () from /usr/local/omniorb-4.2.1/lib/
#24 0xb7d667af in Tango::create_PyPerThData (info=...) at ../../../../lib/cpp/server/utils.cpp:3234
#25 0xb74f07b9 in omniAsyncWorkerInfo::run() () from /usr/local/omniorb-4.2.1/lib/
#26 0xb74f11b2 in omniAsyncWorker::run(void*) () from /usr/local/omniorb-4.2.1/lib/
#27 0xb7027687 in omni_thread_wrapper () from /usr/local/omniorb-4.2.1/lib/
#28 0xb6cfd96e in start_thread (arg=0xb2c87b70) at pthread_create.c:300
#29 0xb6de43fe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

@aleolivo aleolivo changed the title Segmentation fault, after execute state command/attribute, at check_level_alarm Segmentation fault, after execution state command/attribute, at check_level_alarm Dec 13, 2016
@aleolivo aleolivo changed the title Segmentation fault, after execution state command/attribute, at check_level_alarm Segmentation fault after execution state command/attribute, at check_level_alarm Dec 13, 2016
@bourtemb bourtemb added the bug label Dec 14, 2016

This comment has been minimized.

Copy link

commented May 23, 2019

Hi @aleolivo,

Thanks for a detailed bug report and a code with reproduction. The issue is still visible in 9.3.3.
The segfault is due to the access to *value.ush_seq, which was deleted a moment before.

I'm working on a solution.

@mliszcz mliszcz self-assigned this May 23, 2019
@mliszcz mliszcz moved this from To Do to In Progress in Tango 9 Long Term Support May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.