Using RTT::ReadOnlyPointer's on orocos ports leads to a CORBA exception

[saarnold]

The problem seems to occure since the last commit by @smits.

After some samples are handled a corba exception is thrown:

34.326 [ ERROR  ][Logger] caught CORBA exception while reading a remote channel: UNKNOWN UNKNOWN_UserException

and

omniORB: WARNING -- method 'read' raised an unexpected
 std::exception (not a CORBA exception):
 trying access the value inside an unset smart pointer

[smits]

The commit fixed a lot of segfaults we had. Could you provide some kind of a backtrace to pin-point where it goes wrong in your usecase?

[meyerj]

Do you also have @doudou's latest commit eb9952eee97ad392b4c2e6deae6895e55a1c73dc?

[saarnold]

Yes, it happens also with the commit from @doudou, and also on the current master.

Here is the backtrace:

#0  0x00007fe1c0115a30 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007fe1c0a0e34f in RTT::corba::CDataFlowInterface_i::getPortType(char const*) ()
   from /home/sirius/entern/install/lib/liborocos-rtt-corba-gnulinux.so.2.8
#2  0x00007fe1c0a3c347 in _0RL_lcfn_8fd6acea43f2a3c6_11000000(omniCallDescriptor*, omniServant*) ()
   from /home/sirius/entern/install/lib/liborocos-rtt-corba-gnulinux.so.2.8
#3  0x00007fe1c06bb361 in omniCallHandle::upcall(omniServant*, omniCallDescriptor&) ()
   from /usr/lib/libomniORB4.so.1
#4  0x00007fe1c0a437b9 in RTT::corba::_impl_CDataFlowInterface::_dispatch(omniCallHandle&) ()
   from /home/sirius/entern/install/lib/liborocos-rtt-corba-gnulinux.so.2.8
#5  0x00007fe1c0a4f6de in RTT::corba::_impl_CService::_dispatch(omniCallHandle&) ()
   from /home/sirius/entern/install/lib/liborocos-rtt-corba-gnulinux.so.2.8
#6  0x00007fe1c06ad07d in omni::omniOrbPOA::dispatch(omniCallHandle&, omniLocalIdentity*) ()
   from /usr/lib/libomniORB4.so.1
#7  0x00007fe1c0691b38 in omniLocalIdentity::dispatch(omniCallHandle&) () from /usr/lib/libomniORB4.so.1
#8  0x00007fe1c06d6109 in omni::GIOP_S::handleRequest() () from /usr/lib/libomniORB4.so.1
#9  0x00007fe1c06d6f48 in omni::GIOP_S::dispatcher() () from /usr/lib/libomniORB4.so.1
#10 0x00007fe1c06d3925 in omni::giopWorker::real_execute() () from /usr/lib/libomniORB4.so.1
#11 0x00007fe1c06d403f in omni::giopWorker::execute() () from /usr/lib/libomniORB4.so.1
#12 0x00007fe1c068481d in omniAsyncWorkerInfo::run() () from /usr/lib/libomniORB4.so.1
#13 0x00007fe1c0684e4f in omniAsyncWorker::run(void*) () from /usr/lib/libomniORB4.so.1
#14 0x00007fe1c03be673 in omni_thread_wrapper () from /usr/lib/libomnithread.so.3
#15 0x00007fe1c5c07182 in start_thread (arg=0x7fe1827fc700) at pthread_create.c:312
#16 0x00007fe1bf8d000d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

But the error msg comes from rtt/transports/corba/RemoteChannelElement.hpp:259

[jakobs]

I get the same error.

[meyerj]

The error message you posted above is caused by a runtime_error exception thrown in https://github.com/orocos-toolchain/orogen/blob/master/lib/orogen/templates/typekit/smart_ptr.cpp. I think the changes in RemoteChannelElement.hpp in 0e1ead2db34601508a7fcdb5ff7c57d90eb53beb only revealed a bug that already existed before and which is not specific to ReadOnlyPointer. The read call to a remote channel element always invokes the transport's updateAny() method in RemoteChannelElement.hpp:285, but for the case it returns OldData and the copy_old_data flag is set to false the sample in the ValueDataSource has never been set. This triggers the "trying access the value inside an unset smart pointer" exception in case of a ReadOnlyPointer sample. Without the new patches in 0e1ead2db34601508a7fcdb5ff7c57d90eb53beb this bug was not triggered because the persistent ValueDataSource still contained the data from a previous read call which have been transferred instead.

I found no easy way to reproduce the problem and I do not know how to generate a typekit for ReadOnlyPointer with orogen, but I prepared a patch in the fix-corba-read-old-data branch. Could you please test and report if it fixes the problem for you or post an example that triggers the error?

[saarnold]

Your patch fixes the problem for me :) Thank you!