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

[Mifflin Mabalot]

Hi Duncan,
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.
> 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.


>> Maybe I need to give some more info about this, the IDL I used has the following:

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)...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.
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.  (Keep in mind m_HelloObj is declared as _var, so I was expecting that anything the object allocates, even those allocated through it's member methods, would automatically be deallocated upon destruction).

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

>> Thank you for this, I never thought of doing that because I was expecting something like Version 2 would work just fine without any leaks.

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);
>> I think the LOCATION_FORWARD exception has something to do with this (upon "changing" location and retrying to resolve).  I am still setting up my test environment so that no LOCATION_FORWARD exception will occur (or is this inevitable?, any suggestions on how to if not?) and see if it does not leak.  I am using the "native" JAVA orb for the other end/server-side (both persistent and transient).

Thank you and I hope you stay with me to resolve this issue :) ...appreciate it!

Regards,
Miff



On Wednesday, December 11, 2013 7:50 PM, Duncan Grisby <duncan at grisby.org> wrote:
 
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 --
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20131211/67e3ca09/attachment.html>