This forum has been archived. Please start a new discussion on GitHub.

Sporadic SegFaults or no Ice::NoObjectFactoryException


I have a setup where I request data via a RPC from a proxy as fast as it can, which is written by another proxy.
Sporadically I get segFaults in the getter-Function before my code is called or I get an Ice::NoObjectFactoryException with type ::IceObject.
In case of the Ice::NoObjectFactoryException it seems to have the right data before it is send via Ice (the ice_ids() have the correct values) and on the other side the exception is thrown.

In pseudo code the setup looks like this
    App2->proxy->getDatafield(...); //throws sporadically Ice::NoObjectFactoryException with type ::IceObject


class myclass : public myinterface
    MyDataTypePtr getDatafield() //before this get called by Ice, a segfault sporadically happens
        ScopedLock lock(mutex);
        return data;
    void setDatafield(MyDataTypePtr newData)
         ScopedLock lock(mutex);
         data = newData;
    MyDataTypePtr data;


The segfaults backtrace is:
1       0x7f5d51b79411 handlerFault(int) + 185
2       0x7f5d508ec150 /lib/x86_64-linux-gnu/ [0x7f5d508ec150]
3       0x7f5d54237fe5 IceInternal::upCast(Ice::Object*) + 5
4       0x7f5d532298c8 IceInternal::Handle<Ice::Object>::Handle(Ice::Object*) + 66
5       0x7f5d515802f0 armarx::VariantBase::__write(IceInternal::BasicStream*) const + 94
6       0x7f5d541997bd IceInternal::BasicStream::writeInstance(IceInternal::Handle<Ice::Object> const&, int) + 189
7       0x7f5d5419d390 IceInternal::BasicStream::writePendingObjects() + 464
8       0x7f5d5150a594 armarx::ObserverInterface::___getDataField(IceInternal::Incoming&, Ice::Current const&) + 270
9       0x7f5d52ce05ce memoryx::ObjectMemoryObserverInterface::__dispatch(IceInternal::Incoming&, Ice::Current const&) + 494
10      0x7f5d541eb0fe IceInternal::Incoming::invoke(IceInternal::Handle<IceInternal::ServantManager> const&) + 2318
11      0x7f5d541c3231 Ice::ConnectionI::invokeAll(IceInternal::BasicStream&, int, int, unsigned char, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&) + 289
12      0x7f5d541c4cae Ice::ConnectionI::dispatch(IceUtil::Handle<Ice::ConnectionI::StartCallback> const&, std::vector<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback>, std::allocator<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback> > > const&, unsigned char, int, int, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&, IceInternal::Handle<IceInternal::OutgoingAsync> const&, IceInternal::BasicStream&) + 350
13      0x7f5d541c5ad1 Ice::ConnectionI::message(IceInternal::ThreadPoolCurrent&) + 3329
14      0x7f5d542c6fb0 IceInternal::ThreadPool::run(IceUtil::Handle<IceUtil::Thread> const&) + 176
15      0x7f5d542c79ed IceInternal::ThreadPool::EventHandlerThread::run() + 125
16      0x7f5d53e7d96f /usr/lib/ [0x7f5d53e7d96f]
17      0x7f5d51e23e9a /lib/x86_64-linux-gnu/ [0x7f5d51e23e9a]
18      0x7f5d509aa31d clone + 109

All calls in my functions are protected by the same mutex, so there shouldnt be any problems with concurrent access.

I have no idea how debug this because it only happens sometimes and it does not segfault in my code.

Any help is very much appreciated.



  • How can I edit my post above?

    The Ice calls are thread safe right? So, there shouldnt be any problems with concurrent calls to interface function.
  • So, i made 3 example apps to test that.

    Without mutex on my value, it crashes with a similar backtrace to something in Ice.
    With a mutex, it does not crash.

    So maybe, something in my real app is also not correctly mutexed in my code.

    I'll be back ;).
  • benoit
    benoit Rennes, France

    It sounds like another thread is modifying the object returned by getDatafield while it is being marshaled by the Ice runtime. See Thread Safety in the manual for more information on this.

  • Thanks, that seemed to be the problem.
    I was not assigning a new object in the setter, but just updating the old object.

    It ran now for several minutes and didnt crash.