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

[Mifflin Mabalot]

Hi Duncan,

Thank you for all your reply.

If those really are both _var types, then I'm sure it is not actually
leaking.
>> I think I just have to trust you on this for now, even though VS is reporting it as a leak (yeah at times Microsoft's debugger reports the weirdest things unlike any other).  Got to get some serious reading on the CORBA C++ mapping.  Thank you and more power. Merry Christmas!

Regards,
Miff





On Saturday, December 21, 2013 2:02 AM, Duncan Grisby <duncan at grisby.org> wrote:
  
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/--
>
>
>
>
>     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20131222/86265aff/attachment.html>