[omniORB] possible leak in servant_to_reference

[mike o]

Hello,

I'm experiencing what seems to be a leak in servant_to_reference. I have a
server application running in thread-per-connection mode which fulfills both
synchronous and asynchronous requests. For asynchronous requests, a
callback object reference to the client application is passed into the
server application allowing the server application to notify the client
application of the completion of an asynchronous request. This all works
fine and dandy.

Recently, a new interface has been added to the server application that
invokes an old-interface request under the implementation of the new
interface. This new interface has a new callback interface as well. For
asynchronous requests, a relay mechanism was implemented as a servant that
implements the old callback interface and stores an object reference to the
new callback interface passed in by the client application. When the
old-style callback interface's done() method is invoked (signifying that the
asynchronous request has completed), the relay servant translates this into
a new_done() on the client application's object reference.

The life cycle of a relay servant (RelayServant) is as follows: When a new
request is submitted, a RelayServant is created on the heap and activated.
When the RelayServant's new_done() method is invoked, the RelayServant is
deactivated and destroyed by omniORB. Originally, the RelayServant was
invoking deactivate_object() from within the context of it's new_done()
method. The RelayServant's destructor was indeed being called. However,
just to be safe, I moved the deactivate_object() call to another thread and
the same leak persists.

Here is the relevant portions of the memory leak report:

==1323== at 0x4A06019: operator new(unsigned long)
(vg_replace_malloc.c:167)
==1323== by 0x8AEA62:
MyServer::Callbacks::_pof_MyCallback::newObjRef(omniIOR*, omniIdentity*)
(MyServer_SK.cpp:3202)
==1323== by 0x5983B3E: omni::createObjRef(char const*, omniIOR*, bool,
omniIdentity*) (omniInternal.cc:1064)
==1323== by 0x5983F99: omni::createLocalObjRef(char const*, char const*,
omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1151)
==1323== by 0x599B1FE:
omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*)
(poa.cc:1578)
==1323== by 0x6CB691:
_ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb
(Corba.h:511)
==1323== by 0x6A1FE4:
RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback,
MyServer::Callbacks::MyCallback_Helper>&) (RelayServant.h:445)


==1323== at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
==1323== by 0x5978E24:
_CORBA_Sequence<IOP::TaggedProfile>::allocbuf(unsigned)
(seqTemplatedecls.h:174)
==1323== by 0x5978E8E:
_CORBA_Sequence<IOP::TaggedProfile>::copybuffer(unsigned)
(seqTemplatedecls.h:291)
==1323== by 0x5978FA0:
_CORBA_Sequence<IOP::TaggedProfile>::length(unsigned)
(seqTemplatedecls.h:158)
==1323== by 0x598838A: omniIOR::omniIOR(char const*, unsigned char
const*, int, omniIORHints const&) (omniIOR.cc:168)
==1323== by 0x5983F7B: omni::createLocalObjRef(char const*, char const*,
omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1149)
==1323== by 0x599B1FE:
omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*)
(poa.cc:1578)
==1323== by 0x6CB691:
_ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb
(Corba.h:511)
==1323== by 0x6A1FE4:
RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback,
MyServer::Callbacks::MyCallback_Helper>&)
(RelayServant.h:445)


Answers to questions that may arise:
1. I am using PortableServer::ObjectId_var to destroy the object reference
returned by the call to poa->activate_object()
2. I am using CORBA::Object_var to destroy the object reference returned by
poa->servant_to_reference()
3. I am calling relayServant->_remove_ref() just after activation so that
the call to deactivate_object() destroys the instance
4. Every created RelayServant instance is being destroyed


Can anyone help me understand why this leak is happening or what I can do to
fix it? I have considered recycling RelayServant instances, but I cannot be
certain that one request will not affect another in the event that a
RelayServant is returned to the pool/queue but still held by errant request
code. The most simple and safe thing to do is deactivate and destroy the
RelayServant once it has been used.


Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110428/78d7fd09/attachment.htm

[mike o]

After inspecting the omniORB code, I was able to determine that the leak was
being caused by some older server application code, not the omniORB code.

The valgrind output shows that a local object reference is what was being
leaked. I followed the object references around and found that some old
code was narrowing an object reference provided by the new relay servant,
but was storing the result of the narrow() operation in a _ptr type and not
releasing it (or using a _var type).

Everything else worked as expected.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110428/ecba3770/attachment.htm

[mike o]

After inspecting the omniORB code, I was able to determine that the leak was
being caused by some older server application code, not the omniORB code.

The valgrind output shows that a local object reference is what was being
leaked. I followed the object references around and found that some old
code was narrowing an object reference provided by the new relay servant,
but was storing the result of the narrow() operation in a _ptr type and not
releasing it (or using a _var type).

Everything else worked as expected.

Mike

Post by mike o
Hello,
I'm experiencing what seems to be a leak in servant_to_reference. I have a
server application running in thread-per-connection mode which fulfills both
synchronous and asynchronous requests. For asynchronous requests, a
callback object reference to the client application is passed into the
server application allowing the server application to notify the client
application of the completion of an asynchronous request. This all works
fine and dandy.
Recently, a new interface has been added to the server application that
invokes an old-interface request under the implementation of the new
interface. This new interface has a new callback interface as well. For
asynchronous requests, a relay mechanism was implemented as a servant that
implements the old callback interface and stores an object reference to the
new callback interface passed in by the client application. When the
old-style callback interface's done() method is invoked (signifying that the
asynchronous request has completed), the relay servant translates this into
a new_done() on the client application's object reference.
The life cycle of a relay servant (RelayServant) is as follows: When a new
request is submitted, a RelayServant is created on the heap and activated.
When the RelayServant's new_done() method is invoked, the RelayServant is
deactivated and destroyed by omniORB. Originally, the RelayServant was
invoking deactivate_object() from within the context of it's new_done()
method. The RelayServant's destructor was indeed being called. However,
just to be safe, I moved the deactivate_object() call to another thread and
the same leak persists.
==1323== at 0x4A06019: operator new(unsigned long)
(vg_replace_malloc.c:167)
MyServer::Callbacks::_pof_MyCallback::newObjRef(omniIOR*, omniIdentity*)
(MyServer_SK.cpp:3202)
==1323== by 0x5983B3E: omni::createObjRef(char const*, omniIOR*, bool,
omniIdentity*) (omniInternal.cc:1064)
==1323== by 0x5983F99: omni::createLocalObjRef(char const*, char const*,
omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1151)
omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*)
(poa.cc:1578)
_ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb
(Corba.h:511)
RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback,
MyServer::Callbacks::MyCallback_Helper>&) (RelayServant.h:445)
==1323== at 0x4A05CB9: operator new[](unsigned long)
(vg_replace_malloc.c:199)
_CORBA_Sequence<IOP::TaggedProfile>::allocbuf(unsigned)
(seqTemplatedecls.h:174)
_CORBA_Sequence<IOP::TaggedProfile>::copybuffer(unsigned)
(seqTemplatedecls.h:291)
_CORBA_Sequence<IOP::TaggedProfile>::length(unsigned)
(seqTemplatedecls.h:158)
==1323== by 0x598838A: omniIOR::omniIOR(char const*, unsigned char
const*, int, omniIORHints const&) (omniIOR.cc:168)
==1323== by 0x5983F7B: omni::createLocalObjRef(char const*, char const*,
omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1149)
omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*)
(poa.cc:1578)
_ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb
(Corba.h:511)
RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback,
MyServer::Callbacks::MyCallback_Helper>&)
(RelayServant.h:445)
1. I am using PortableServer::ObjectId_var to destroy the object reference
returned by the call to poa->activate_object()
2. I am using CORBA::Object_var to destroy the object reference returned by
poa->servant_to_reference()
3. I am calling relayServant->_remove_ref() just after activation so that
the call to deactivate_object() destroys the instance
4. Every created RelayServant instance is being destroyed
Can anyone help me understand why this leak is happening or what I can do
to fix it? I have considered recycling RelayServant instances, but I cannot
be certain that one request will not affect another in the event that a
RelayServant is returned to the pool/queue but still held by errant request
code. The most simple and safe thing to do is deactivate and destroy the
RelayServant once it has been used.
Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20110428/60bba8d1/attachment-0001.htm