[omniORB] Re: possible leak in servant_to_reference

[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

On Thu, Apr 28, 2011 at 11:06 AM, mike o <mike.otj at gmail.com> wrote:

> 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/60bba8d1/attachment-0001.htm