Uncaught DevFailed exception in DeviceProxy destructor in cxx_stateless_subscription testcase

[mliszcz]

Hello,
I got following error every time I run stateless_subscription testcase:

38: terminate called after throwing an instance of 'Tango::DevFailed'
1/1 Test #38: CXX::cxx_stateless_subscription ...Child aborted***Exception:  55.67 sec

I'm using:

• cppTango tango-9-lts, 07eea09
• gcc 8.2.1 20181127
• libzmq built from tag v4.3.0

DevFailed is being thrown in device2 destructor:

cppTango/cpp_test_suite/new_tests/cxx_stateless_subscription.cpp

Lines 88 to 95 in 07eea09

	virtual ~SUITE_NAME() {
	if (CxxTest::TangoPrinter::is_restore_set("test2/debian8/20 started."))
	CxxTest::TangoPrinter::kill_server();
	CxxTest::TangoPrinter::start_server("test");
	delete device2;
	}

The root cause of the exception is disconnect failure in heartbeat socket:

cppTango/cppapi/client/zmqeventconsumer.cpp

Line 836 in 07eea09

heartbeat_sub_sock->disconnect(endpoint);

errno is being set to ENOENT. This means that given endpoint was already disconnected. Indeed SUB socket is disconnected when PUB endpoint is terminated (kill_server call).

The workaround is to delete device2 proxy before kill_server is called.

A proper fix would be to handle disconnection failure (at least the one due to ENOENT) in zmqeventconsumer.cpp. I can submit a patch if you're ok with such a solution.

Probably there are other scenarios where exception can be thrown in a destructor. Such exception will always result in a call to terminate (as destructor is implicitly noexcept).

[bourtemb]

A proper fix would be to handle disconnection failure (at least the one due to ENOENT) in zmqeventconsumer.cpp. I can submit a patch if you're ok with such a solution.

Indeed, this would be clean. The ENOENT case is something which should not be considered as an error when we want to disconnect. Please feel free to submit a patch.

Probably there are other scenarios where exception can be thrown in a destructor. Such exception will always result in a call to terminate (as destructor is implicitly noexcept).

I think we should also surround the call to unsubscribe_event() in ~DeviceProxy with a try/catch too.
I agree with you when you write:

Probably there are other scenarios where exception can be thrown in a destructor. Such exception will always result in a call to terminate (as destructor is implicitly noexcept).