Issue 3539: Variable-length out params and exceptions (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the spec is currently not terribly clear about the server's responsibilities when throwing an exception from an operation that has a variable-length out param. The intent of the spec is that the server is responsible for deleting the memory it allocated to an out param before it throws an exception: // Correct implementation void Foo_impl:: op(CORBA::String_out out_p) throw(CORBA::SystemException) { CORBA::String_var tmp = CORBA::string_dup("Hello"); bar(); // bar() may throw out_p = tmp._retn(); // No leak, even if bar() throws } // Incorrect implementation void Foo_impl:: op(CORBA::String_out out_p) throw(CORBA::SystemException) { out_p = CORBA::string_dup("Hello"); bar(); // Leak if bar() throws } However, the spec never states this clearly. In fact, it sort of says the opposite. On page 1-110, table item 3: To maintain local/remote transparency, the caller must always release the returned storage, regardless of whether the callee is located in the same address space as the caller or is located in a different address space. There is no mention here of what should happen in the presence of exceptions. I think it would be nice to clarify that the skeleton will never look at an out param in the presence of exceptions and that the operation implementation is responsible for deallocating memory in this case. Resolution: Revised Text: Actions taken: April 11, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Date: Tue, 11 Apr 2000 13:25:25 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: Variable-length out params and exceptions Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %d[!!@f`d9XS[d9)Nh!! Hi, the spec is currently not terribly clear about the server's responsibilities when throwing an exception from an operation that has a variable-length out param. The intent of the spec is that the server is responsible for deleting the memory it allocated to an out param before it throws an exception: // Correct implementation void Foo_impl:: op(CORBA::String_out out_p) throw(CORBA::SystemException) { CORBA::String_var tmp = CORBA::string_dup("Hello"); bar(); // bar() may throw out_p = tmp._retn(); // No leak, even if bar() throws } // Incorrect implementation void Foo_impl:: op(CORBA::String_out out_p) throw(CORBA::SystemException) { out_p = CORBA::string_dup("Hello"); bar(); // Leak if bar() throws } However, the spec never states this clearly. In fact, it sort of says the opposite. On page 1-110, table item 3: To maintain local/remote transparency, the caller must always release the returned storage, regardless of whether the callee is located in the same address space as the caller or is located in a different address space. There is no mention here of what should happen in the presence of exceptions. I think it would be nice to clarify that the skeleton will never look at an out param in the presence of exceptions and that the operation implementation is responsible for deallocating memory in this case. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "'C++ Revision Task Force'" Subject: RE: Variable-length out params and exceptions Date: Tue, 11 Apr 2000 08:30:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 83^d9]-hd91(""!?9!"! Michi - I think I agree with your intent, but I want to make sure about one point: Often (usually) the caller will pass a _var to receive an out argument. In this case, even if there is an exception, the value of the out param will indeed be touched by the _var's destructor. This should of course be legal. I think the effect of this is that out arguments that are passed by pointer must, in the case of an exception, either be untouched by the callee or else explicitly set to 0. Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Monday, April 10, 2000 11:25 PM > To: C++ Revision Task Force > Cc: issues@omg.org > Subject: Variable-length out params and exceptions > > > Hi, > > the spec is currently not terribly clear about the server's > responsibilities > when throwing an exception from an operation that has a > variable-length > out param. > > The intent of the spec is that the server is responsible for > deleting > the memory it allocated to an out param before it throws an > exception: > > // Correct implementation > void > Foo_impl:: > op(CORBA::String_out out_p) throw(CORBA::SystemException) > { > CORBA::String_var tmp = CORBA::string_dup("Hello"); > > bar(); // bar() may throw > > out_p = tmp._retn(); // No leak, even if bar() > throws > } > > // Incorrect implementation > void > Foo_impl:: > op(CORBA::String_out out_p) throw(CORBA::SystemException) > { > out_p = CORBA::string_dup("Hello"); > > bar(); // Leak if bar() throws > } > > However, the spec never states this clearly. In fact, it sort of > says > the opposite. On page 1-110, table item 3: > > To maintain local/remote transparency, the caller must always > release the returned storage, regardless of whether the callee > is located in the same address space as the caller or is > located > in a different address space. > > There is no mention here of what should happen in the > presence of exceptions. > > I think it would be nice to clarify that the skeleton will never > look > at an out param in the presence of exceptions and that the operation > implementation is responsible for deallocating memory in this case. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 12 Apr 2000 07:07:10 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'C++ Revision Task Force'" Subject: RE: Variable-length out params and exceptions In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BDC1@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Y"7e9MAWd9:1Ke9V=4e9 On Tue, 11 Apr 2000, Paul Kyzivat wrote: > Michi - I think I agree with your intent, but I want to make sure about one > point: > > Often (usually) the caller will pass a _var to receive an out argument. > In this case, even if there is an exception, the value of the out param will > indeed be touched by the _var's destructor. This should of course be legal. > > I think the effect of this is that out arguments that are passed by pointer > must, in the case of an exception, either be untouched by the callee or else > explicitly set to 0. I think you are right. Basically, if the called operation throws an exception, it must leave the param with a value that is safe to passed to delete (or string_free, or whatever). In the remote case, the skeleton should simply ignore the parameter. However, in the collocated case, the param must be left with value that is safe to delete, otherwise the caller will crash if the callee's param is bound to a _var in the caller. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html