-
Notifications
You must be signed in to change notification settings - Fork 34
DevFailed thrown with several unsubscribe events #620
Comments
Looks similar to tango-controls/pytango#292. |
Hello mliszcz. It looks similar to the issue you cited because the crash happens during the unsubscribe process. Nonetheless, the backtrace is quite different. In the first case it points to DelayEvent constructor, in my case to the class Destructor. And yes, being my library a general purpose, engine independent implementation, C++ 11 threads are employed rather than omniorb's. G. |
Non-omniorb threads (i.e. threads with no omniorb ID assigned) are not supported by Tango. Can you try the
And ensure that the object exists during the lifetime of the thread. |
Hello again. Thanks for Your suggestion. void CuEventActivity::onExit()
{
int refcnt;
if(d->tdev->getDevice() && d->event_id != -1)
try{
d->tdev->getDevice()->unsubscribe_event(d->event_id);
}
catch(Tango::DevFailed &e)
{
// ...
}
}
else if(!d->tdev->getDevice()) {
}
refcnt = d->tdev->removeRef();
if(refcnt == 0)
d->device_srvc->removeDevice(at["device"].toString());
publishResult(at);
// delete omni_thread::ensure_self
if(d->se) delete d->se;
} |
It may be a different issue then. Could you please post:
so that someone may be able to have a look. |
Hello.
When I call unsubscribe_event for a lot of device attributes, I get a:
terminate called after throwing an instance of 'Tango::DevFailed'
terminate called recursively
Aborted (core dumped)
gdb backtrace is as follows:
Core was generated by `./bin/sequencer --load=MasterList'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f960e89a185 in raise () from /usr/lib64/libc.so.6
[Current thread is 1 (LWP 177687)]
(gdb) bt
#0 0x00007f960e89a185 in raise () from /usr/lib64/libc.so.6
#1 0x00007f960e8798a7 in abort () from /usr/lib64/libc.so.6
#2 0x00007f960ec5a53d in ?? () from /usr/lib64/libstdc++.so.6
#3 0x00007f960ec66dda in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00007f960ec65a79 in ?? () from /usr/lib64/libstdc++.so.6
#5 0x00007f960ec6641e in __gxx_personality_v0 () from /usr/lib64/libstdc++.so.6
#6 0x00007f960ea590cd in ?? () from /usr/lib64/libgcc_s.so.1
#7 0x00007f960ea59b5e in _Unwind_Resume () from /usr/lib64/libgcc_s.so.1
#8 0x00007f961117c386 in zmq::message_t::~message_t (this=, __in_chrg=)
at /usr/local/omniorb-4.2.3/include/zmq.hpp:288
#9 Tango::DelayEvent::release (this=) at /home/giacomo/devel/cppTango/cppapi/client/zmqeventconsumer.cpp:4045
#10 0x00007f961133c239 in Tango::DelayEvent::~DelayEvent (this=, __in_chrg=)
at /home/giacomo/devel/cppTango/cppapi/client/zmqeventconsumer.cpp:4038
#11 0x00007f961117655c in Tango::EventConsumer::unsubscribe_event (this=0x7f95e800d780, event_id=event_id@entry=1153)
at /home/giacomo/devel/cppTango/cppapi/server/readers_writers_lock.h:190
#12 0x00007f9611231df8 in Tango::DeviceProxy::unsubscribe_event (this=, event_id=1153)
at /home/giacomo/devel/cppTango/cppapi/client/devapi_base.cpp:8346
#13 0x00007f96104d272b in CuEventActivity::onExit (this=0x5626c9963770) at ../lib/cueventactivity.cpp:247
#14 0x00007f961052bf42 in CuActivity::doOnExit (this=0x5626c9963770) at ../src/lib/cuactivity.cpp:88
#15 0x00007f96105371b5 in CuThread::mExitActivity (this=0x5626c92f30c0, a=0x5626c9963770, onThreadQuit=)
at ../src/lib/threads/cuthread.cpp:531
#16 0x00007f9610537a4e in CuThread::run (this=0x5626c92f30c0) at ../src/lib/threads/cuthread.cpp:389
#17 0x00007f960ec9f824 in ?? () from /usr/lib64/libstdc++.so.6
#18 0x00007f960edc07bf in ?? () from /usr/lib64/libpthread.so.0
#19 0x00007f960e9775c3 in clone () from /usr/lib64/libc.so.6
The backtrace points somewhere inside ~DelayEvent destructor.
At the moment when unsubscribe_event is called in sequence for several connections, there are more than 1500 active device attribute readings, many of them are subscribed to the event system. (I can provide their exact number if needed)
Thanks for Your attention.
Giacomo, Elettra.
The text was updated successfully, but these errors were encountered: