omniORBpy 1.2 bugs

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

Summary: Occasional odd object references (bug number 8)
Date: Wed Feb 14 15:10:33 GMT 2001
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1
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
Fixed by: dpg1

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.