<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt"><div><span>Hi Duncan,</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><span style="font-family: monospace; font-size: 13px;">The original object reference is kept for as long as the application</span><br clear="none" style="font-family: monospace; font-size: 13px;"><span style="font-family: monospace; font-size: 13px;">code holds on to the object reference. The forwarded reference can fail</span><br clear="none" style="font-family: monospace; font-size: 13px;"><span style="font-family: monospace; font-size: 13px;">at any time, and if it does it reverts back to the original location.</span></span></div><div style="color: rgb(0, 0, 0);
font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span><span style="font-family: monospace; font-size: 13px;">> CORBA::WStringValue* l_sayHelloPtr = TaskWork.m_HelloObj->sayHello();</span><br clear="none" style="font-family: monospace; font-size: 13px;"><br clear="none" style="font-family: monospace; font-size: 13px;"><span style="font-family: monospace; font-size: 13px;">You are responsible for releasing the WStringValue pointer. It's a leak</span><br clear="none" style="font-family: monospace; font-size: 13px;"><span style="font-family: monospace; font-size: 13px;">in your code, not in omniORB, if you don't release it.</span><br clear="none" style="font-family: monospace; font-size: 13px;"></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande',
sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent;">>> Maybe I need to give some more info about this, the IDL I used has the following:</span><br></div><div style="background-color: transparent;"><font face="monospace" size="2">module helloInterface {</font></div><div style="background-color: transparent;"><font face="monospace" size="2"> interface HelloInt {</font></div><div style="background-color: transparent;"><font face="monospace" size="2"> ::CORBA::WStringValue sayHello( );</font><span style="font-family: monospace; font-size: 13px; background-color: transparent;"> </span></div><div style="background-color:
transparent;"><font face="monospace" size="2"> };</font></div><div style="background-color: transparent;"><font face="monospace" size="2">#pragma ID HelloInt "RMI:helloInterface.HelloInt:0000000000000000"</font></div><div style="background-color: transparent;"><font face="monospace" size="2">};</font></div><div>When I compiled the IDL using omniidl, it produced the C++ header and implementation files containing this:</div><div><div> CORBA::WStringValue* sayHello();</div><div>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.</div><div>For a first time orb user like me, these two would look the same:</div><div>Version 1:</div><div><div>CORBA::WStringValue_var l_sayHello = TaskWork.m_HelloObj->sayHello();</div><div><span style="font-size: 12pt;">*lClientRequest = l_sayHello->_boxed_out();</span><br></div><div>Version 2:</div><div>*lClientRequest = TaskWork.m_HelloObj->sayHello()->_boxed_out();<br></div><div><br></div><div>...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).</div><div><br></div></div><div><span style="font-family: monospace; font-size: 13px;">Or, probably better, use a _var that automatically calls _remove_ref</span><br clear="none" style="font-family: monospace; font-size: 13px;"><span style="font-family: monospace; font-size: 13px;">when it goes out of scope:</span><br clear="none" style="font-family: monospace; font-size: 13px;"></div><div><div>>> 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.</div><div><br></div><div>But going back to the original problem, why is this causing a leak when all objects are declared as _var?</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m_NSObj = m_ORB->resolve_initial_references("NameService");</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m_RootContext =
CosNaming::NamingContextExt::_narrow(m_NSObj);</div><div>>> 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).</div><div><br></div><div>Thank you and I hope you stay with me to resolve this issue :) ...appreciate it!</div><div><br></div></div><div>Regards,</div><div>Miff</div></div></div><div class="yahoo_quoted" style="display: block;"> <br> <br> <div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"> <div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"> <div dir="ltr"> <font size="2"
face="Arial"> On Wednesday, December 11, 2013 7:50 PM, Duncan Grisby <duncan@grisby.org> wrote:<br> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div class="y_msg_container">On Wed, 2013-12-11 at 15:10 +0800, Mifflin Mabalot wrote:<br clear="none"><br clear="none">> Then if invocations on the new<br clear="none">> location fail, omniORB retries with the original object reference.<br clear="none">> That's important for various implementation repository approaches and<br clear="none">> for object migration support.<br clear="none">> <br clear="none">> >> What happens if invocations on the new location succeed? Is the<br clear="none">> original object reference "deallocated", I think this is what's<br clear="none">> missing<br clear="none"><br clear="none">The original object reference is kept for as long as the application<br
clear="none">code holds on to the object reference. The forwarded reference can fail<br clear="none">at any time, and if it does it reverts back to the original location.<br clear="none"><br clear="none">[...]<br clear="none">> Whenever a remote object is referenced, that too is causing leaks, but<br clear="none">> I found a way to cleanup the leaks by incorporating some extra code,<br clear="none">> see below (maybe the "allocation for every reference" is by design and<br clear="none">> is included in the CORBA specs, but I used a _var (smart pointer)<br clear="none">> which has been discussed as "self-cleaning / self-deallocating" during<br clear="none">> destruction, yet it is leaving behind leaks)<br clear="none"><br clear="none"><br clear="none">[...]<br clear="none">> CORBA::WStringValue* l_sayHelloPtr = TaskWork.m_HelloObj->sayHello();<br clear="none"><br clear="none">You are responsible for releasing the WStringValue
pointer. It's a leak<br clear="none">in your code, not in omniORB, if you don't release it.<br clear="none"><br clear="none">[...]<br clear="none">> // Cleanup to avoid leaks (this simply releases a reference, so that<br clear="none">> the object can clean/deallocate itself)<br clear="none">> CORBA::WStringValue_Helper::remove_ref(l_sayHelloPtr); // >> NOT DOING<br clear="none">> THIS WILL CAUSE LEAKS<br clear="none">> }<br clear="none"><br clear="none">This is a non-standard way to release the pointer. You should call<br clear="none">_remove_ref directly:<br clear="none"><br clear="none"> l_sayHelloPtr->_remove_ref();<br clear="none"><br clear="none">Or, probably better, use a _var that automatically calls _remove_ref<br clear="none">when it goes out of scope:<br clear="none"><br clear="none"> CORBA::WstringValue_var l_sayHelloPtr = ...<div class="yqt0414505201" id="yqtfd17741"><br clear="none"><br clear="none"><br
clear="none">> <br clear="none"><br clear="none">-- <br clear="none"> -- Duncan Grisby --<br clear="none"> -- <a shape="rect" ymailto="mailto:duncan@grisby.org" href="mailto:duncan@grisby.org">duncan@grisby.org</a> --<br clear="none"> -- <a shape="rect" href="http://www.grisby.org/" target="_blank">http://www.grisby.org </a>--<br clear="none"><br clear="none"><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div> </div></body></html>