Hello,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><div>Here is the relevant portions of the memory leak report:</div><div><br></div><div><div><div>==1323== at 0x4A06019: operator new(unsigned long) (vg_replace_malloc.c:167)</div><div>==1323== by 0x8AEA62: MyServer::Callbacks::_pof_MyCallback::newObjRef(omniIOR*, omniIdentity*) (MyServer_SK.cpp:3202)</div>
<div>==1323== by 0x5983B3E: omni::createObjRef(char const*, omniIOR*, bool, omniIdentity*) (omniInternal.cc:1064)</div><div>==1323== by 0x5983F99: omni::createLocalObjRef(char const*, char const*, omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1151)</div>
<div>==1323== by 0x599B1FE: omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*) (poa.cc:1578)</div></div></div><div><div>==1323== by 0x6CB691: _ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb (Corba.h:511)</div>
<div>==1323== by 0x6A1FE4: RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback, MyServer::Callbacks::MyCallback_Helper>&) (RelayServant.h:445)</div></div><div><br>
</div></div><div><br></div><div><div>==1323== at 0x4A05CB9: operator new[](unsigned long) (vg_replace_malloc.c:199)</div><div>==1323== by 0x5978E24: _CORBA_Sequence<IOP::TaggedProfile>::allocbuf(unsigned) (seqTemplatedecls.h:174)</div>
<div>==1323== by 0x5978E8E: _CORBA_Sequence<IOP::TaggedProfile>::copybuffer(unsigned) (seqTemplatedecls.h:291)</div><div>==1323== by 0x5978FA0: _CORBA_Sequence<IOP::TaggedProfile>::length(unsigned) (seqTemplatedecls.h:158)</div>
<div>==1323== by 0x598838A: omniIOR::omniIOR(char const*, unsigned char const*, int, omniIORHints const&) (omniIOR.cc:168)</div><div>==1323== by 0x5983F7B: omni::createLocalObjRef(char const*, char const*, omniObjTableEntry*, omniIORHints const&) (omniInternal.cc:1149)</div>
<div>==1323== by 0x599B1FE: omni::omniOrbPOA::servant_to_reference(PortableServer::ServantBase*) (poa.cc:1578)</div><div>==1323== by 0x6CB691: _ZN5Corba14activateObjectI19RelayServantN13MyServer9Callbacks9MyCallbackEEEbPT_RNT0_9_var_typeEb (Corba.h:511)</div>
<div>==1323== by 0x6A1FE4: RelayServantManager::createRelayServant(_CORBA_ObjRef_Var<MyServer::Callbacks::_objref_MyCallback, MyServer::Callbacks::MyCallback_Helper>&)</div><div> (RelayServant.h:445)</div><div>
<br></div><div><br></div></div><div>Answers to questions that may arise:</div><div>1. I am using PortableServer::ObjectId_var to destroy the object reference returned by the call to poa->activate_object()</div><div>2. I am using CORBA::Object_var to destroy the object reference returned by poa->servant_to_reference()</div>
<div>3. I am calling relayServant->_remove_ref() just after activation so that the call to deactivate_object() destroys the instance</div><div>4. Every created RelayServant instance is being destroyed</div><div><br></div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Thanks,</div><div>Mike</div><div><br></div><div><br></div>