[omniORB] Memory Leak (CosNaming::NamingContextExt::_narrow)

[Duncan Grisby]

On Wed, 2013-12-11 at 15:10 +0800, Mifflin Mabalot wrote:

> Then if invocations on the new
> location fail, omniORB retries with the original object reference.
> That's important for various implementation repository approaches and
> for object migration support.
> 
> >> What happens if invocations on the new location succeed? Is the
> original object reference "deallocated", I think this is what's
> missing

The original object reference is kept for as long as the application
code holds on to the object reference. The forwarded reference can fail
at any time, and if it does it reverts back to the original location.

[...]
> Whenever a remote object is referenced, that too is causing leaks, but
> I found a way to cleanup the leaks by incorporating some extra code,
> see below (maybe the "allocation for every reference" is by design and
> is included in the CORBA specs, but I used a _var (smart pointer)
> which has been discussed as "self-cleaning / self-deallocating" during
> destruction, yet it is leaving behind leaks)


[...]
> CORBA::WStringValue* l_sayHelloPtr = TaskWork.m_HelloObj->sayHello();

You are responsible for releasing the WStringValue pointer. It's a leak
in your code, not in omniORB, if you don't release it.

[...]
> // Cleanup to avoid leaks (this simply releases a reference, so that
> the object can clean/deallocate itself)
> CORBA::WStringValue_Helper::remove_ref(l_sayHelloPtr); // >> NOT DOING
> THIS WILL CAUSE LEAKS
> }

This is a non-standard way to release the pointer. You should call
_remove_ref directly:

  l_sayHelloPtr->_remove_ref();

Or, probably better, use a _var that automatically calls _remove_ref
when it goes out of scope:

  CORBA::WstringValue_var l_sayHelloPtr = ...


>         

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --