#826 unsubscribe_event fails in delete_device

[Giovanni Cerretani]

As reported in the forum post

http://www.tango-controls.org/community/forum/c/development/python/unsubscribe_event-fails-in-delete_device/

I can't shutdown a PyTango server that is running more than one Device subscribed to a certain attribute event.

The unsubscribe_event(...) is called in delete_device().

Currently each Device of my server is subscribed to two events, but I have problems only with the first type of event. More details are explained in the forum post. No problem on deleting and recreating the devices with the Init() command, but only when killing the whole server.

The one that makes problems is a spectrum of 8 DevUShort, while the one that works is a spectrum of 8 DevBoolean. If I do not subscribe to the DevUShort attribute, everything is killed correctly.

This is the exception raised by unsubscribe_event(...) called in delete_device().

DevFailed[
DevError[
    desc = Failed to disconnect from event!
           Error while trying to unsubscribe the heartbeat ZMQ socket from the channel heartbeat publisher
           ZMQ message: No such file or directory
  origin = ZmqEventConsumer::disconnect_event
  reason = API_ZmqFailed
severity = ERR]
]

In this case I have to press CTRL+C several times, and at the end I get a segmentation fault here:

#0 0x00007f6867101b98 in set_svr_shutting_down (this=0x1db1690) at ../../../../lib/cpp/server/utils.h:893
#1 Tango::Util::shutdown_server (this=0x1db1690) at ../../../../lib/cpp/server/utils_shut.cpp:79
#2 0x00007f68670f0175 in Tango::DServerSignal::ThSig::run_undetached (this=0x1ddf510, ptr=<value optimized out>) at ../../../../lib/cpp/server/thsig.cpp:202
#3 0x00007f6865936e7e in omni_thread_wrapper () from /virgo/ext/omniORB/omniORB-4.1.4/Linux-x86_64-SL6/lib/libomnithread.so.3
#4 0x000000379dc07a51 in start_thread () from /lib64/libpthread.so.0
#5 0x000000379d0e896d in clone () from /lib64/libc.so.6

[Giovanni Cerretani]

I can reproduce the problem creating a new attribute "fakeAttr" in my low level device, a Scalar - DevUShort[12]:

attr_fakeAttr_read = new Tango::DevUShort[12];

I set a polling time and a relative change of 1% in POGO. I do not check any "Pushed events by user code". The device is coded in C++. I do not fill any of the methods created by POGO. Then I subscribe to it in a PyTango device, with

DeviceProxy('...').subscribe_event('fakeAttr', PyTango.EventType.CHANGE_EVENT, self.test, filters=[], stateless=True)

in two devices running on the same server. Everithing works, also the delete_device() invoked by the Init() function, but I can't kill the server properly, getting the problem described in the previous post.

Other notes:

I get the same error also with a scalar attribute, managed only on periodic events. After the first event, it is impossible to kill the server. If subscribe to change events but I do not manage them in the low level device (i.e. no event is pushed, neither the one at the subscription time), then I've no problem.

The strange thing is that this server is subscribing correctly change events of another PyTango low level device. I've no problem with that attribute.

[Emmanuel Taurel]

Hello,

I am not able to reproduce this problem. I am using Tango 9 in C++. I have "low level"
devices with state, att1 and att2 (spectrum - DevUShort) correctly configured to generate change event. I have "high level" devices (3 to be precise) in another DS. In their init_device, they
1- Connect to low level device. Each high level dev have a different low level dev.
2- Subscribe to change_event on state, att1 and att2 from the low level dev
3-Store event id(s) in the object
In their delete_device method, those devices unsubscribe from the events

I am able to "control C" the DS, to do Init command and also to do RestartDevice on their
admin device.

Do you confirm that you have the problem using Tango 9?

Sincerely

Emmanuel

[Giovanni Cerretani]

The bug is not trivial at all. In this months I made some tests, but I'm confused.

I am using Tango 9.2.2 in the C++ low level server, and the PyTango 8.1.8 in the high level one.

[Giovanni Cerretani]

The problem seems resolved if I use the latest 9.2.0 version of PyTango from github.