omniORB 3.0.3 bugs

The following bugs in omniORB 3.0.3 have been fixed. Update from Subversion to get the fixes.

Summary: System clock change causes the scavenger thread to consume lots of CPU cycles (bug number 7)
Date: Tue May 29 12:14:54 BST 2001
Reported by: Peter Rönnquist
Description: Scavenger now get the real time after each scan. This is to cope with the system clock set backward by a large amount. Seems to happen a lot to some system..

Summary: Incorrect namespaces for MSVC++ constant work-around (bug number 6)
Date: Fri Apr 27 11:58:25 BST 2001
Reported by: Daniel Bell
Description: The code generated to give constants external linkage on MSVC failed for nested modules.

Summary: Incorrect code generated for includes at non-file scope (bug number 5)
Date: Wed Apr 25 17:49:17 BST 2001
Reported by: Olaf Meding
Description: The IDL compiler C++ back-end would generate incorrect code for #includes at non-file scope. Now, declarations inside files #included at non-file scope are treated as if they appeared in the including file.

Summary: Bug in ORB core causes assertion failure (bug number 4)
Date: Tue Mar 27 17:56:31 BST 2001
Reported by: Roumen Ivanov
Description: A bug in the ORB core would causes an assertion failure when an object is deactivated. The problem occurs if the object has local references whose c++ type disagrees with that of the object.

This may explain a problem with omniNames, given in the link above.

Summary: Incorrect TypeCode for union with multiple case labels (bug number 3)
Date: Wed Mar 21 16:31:13 GMT 2001
Reported by: Clemens Fischer
Description: The generated TypeCode for a union with multiple case labels would have the wrong member count. e.g. the count for

  union U switch (long) {
    case 1:
    case 2: long l;
    case 3: string s;
would be 2 instead of 3.

Summary: Incorrect DynSK stubs for some recursive types (bug number 2)
Date: Tue Mar 20 16:55:07 GMT 2001
Reported by: Lars Immisch
Description: The IDL compiler C++ back-end would generate incorrect TypeCode constants for IDL like

    struct S {
      sequence <sequence <S> > a;

Summary: Memory corruption when initialising multiply-recursive structures (bug number 1)
Date: Tue Mar 20 16:55:07 GMT 2001
Reported by: Marcus Bullingham
Description: IDL types where there was more than one recursion to the same type would corrupt memory, sometimes leading to a crash.