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

[Duncan Grisby]

On Wed, 2013-12-11 at 21:23 +0800, Mifflin Mabalot wrote:

[...]
> module helloInterface {
>     interface HelloInt {
>         ::CORBA::WStringValue sayHello( );    
>     };
> #pragma ID HelloInt "RMI:helloInterface.HelloInt:0000000000000000"
> };
> When I compiled the IDL using omniidl, it produced the C++ header and
> implementation files containing this:
>     CORBA::WStringValue* sayHello();
> At first I was not expecting (DID NOT NOTICE) sayHello() would return
> a pointer since the method signature in the IDL file does not (or
> maybe this is my fault for not reading the CORBA specs)...

You really really have to understand the C++ mapping. It's horrible and
ugly, and has complex memory management rules. If you don't understand
the rules, you will get it wrong and your code will leak or, worse,
crash.

> I just came to realize when I eventually noticed that the return value
> is a pointer...that sayHello() method was probably doing some internal
> allocations.  I am just wondering though, if you take a look at the
> declaration, I declared a _var object (m_HelloObj)..but the sayHello
> method (which is a member of the object m_HelloObj) isn't doing an
> automatic cleanup.  In short, the _var object itself is automatically
> cleaning up it's allocations, but not allocations made by its member
> methods.

Yes, the object reference _var type (HelloInt_var) looks after ownership
of the object reference. It does not have any bearing at all on
ownership of values returned from methods on the object.

> For a first time orb user like me, these two would look the same:
> Version 1:
> CORBA::WStringValue_var l_sayHello = TaskWork.m_HelloObj->sayHello();
> *lClientRequest = l_sayHello->_boxed_out();
> 
> Version 2:
> *lClientRequest = TaskWork.m_HelloObj->sayHello()->_boxed_out();

> ...but they don't perform the same, Version 1 doesn't cause leaks,
> Version 2 does.

That is correct. It's awkward, but those are the rules of the standard
CORBA C++ mapping.

[...]
> But going back to the original problem, why is this causing a leak
> when all objects are declared as _var?
> m_NSObj = m_ORB->resolve_initial_references("NameService");
> m_RootContext = CosNaming::NamingContextExt::_narrow(m_NSObj);

If those really are both _var types, then I'm sure it is not actually
leaking.

> >> I think the LOCATION_FORWARD exception has something to do with
> this (upon "changing" location and retrying to resolve).

No, the LOCATION_FORWARD will not cause it to leak. For as long as the
object reference is alive (which because it's an initial reference is
likely to be for the whole lifetime of the process), it will have
storage for both the original location and the forwarded location, but
that's not a leak.

Duncan.

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