omniORBpy 1.2 bugs

The following bugs in omniORBpy 1.2 have been fixed. Update from Subversion to get the fixes.


Summary:	Occasional odd object references (bug number 8)
Date:	Wed Feb 14 15:10:33 GMT 2001
Description:	POA functions like id_to_reference() would occasionally return base CORBA.Object rather than the most derived type. This was due to using a freed repository id string.

Summary:	Crash when marshalling CORBA::Object TypeCode (bug number 7)
Date:	Thu Jan 18 11:45:43 GMT 2001
Reported by:	Lars von Wedel
Description:	The TypeCode marshaller would calculate the correct size for a base CORBA::Object TypeCode, but then marshal it incorrectly, leading to an error from an omniORB sanity check.

Summary:	BAD_TYPECODE exception with good TypeCode (bug number 6)
Date:	Mon Dec 4 17:56:07 GMT 2000
Reported by:	Harri Pasanen
Description:	The TypeCode unmarshalling code would fail to record offsets within TypeCodes it already knew, so indirections to them would fail.

Summary:	Deadlock with concurrent calls to _this() (bug number 5)
Date:	Wed Nov 29 17:01:06 GMT 2000
Reported by:	Mike Olson
Description:	In various circumstances, omniORBpy could deadlock due to holding an omniORB internal lock at inappropriate times. This bug was provoked by the fix to bug 6 in omniORBpy 1.1.

Summary:	Segfault in string_to_object (bug number 4)
Date:	Tue Nov 21 10:46:54 GMT 2000
Reported by:	Nick Belshaw
Description:	string_to_object would segfault if it returned a nil object reference.

Summary:	Unnecessary call to _is_a() after narrow() (bug number 3)
Date:	Thu Nov 2 17:41:22 GMT 2000
Description:	After a call to _narrow(), an unnecessary call to _is_a() would be made on the first call to the narrowed reference.

Summary:	Recursive structs inside interfaces (bug number 2)
Date:	Wed Nov 1 11:21:45 GMT 2000
Description:	The IDL compiler would generate incorrect code for recursive structs declared within interfaces.

Summary:	Premature deletion of Python thread state (bug number 1)
Date:	Mon Oct 9 09:54:53 BST 2000
Description:	If a servant method makes a call into omniORB which requires the ORB to make another up-call to Python, the thread state for the call is marked as inactive when the up-call finishes, even though the servant call is still in progress. If the method takes more than a minute to complete, without making any more re-entrant up-calls, the thread state will be deleted while the thread is still running. This is not the problem described here, which is due to mixing threads created with the `thread` package with primitives from the `threading` package.