omniORB 3.0.2 Bug List

attlogo6876_dk.gif (2280 bytes)

sideHome.gif (2321 bytes)sideDownload.gif (2450 bytes)sideDocumentation.gif (2512 bytes)sideFAQ.gif (2344 bytes)sidePatch.gif (2543 bytes)sideSearch.gif (2403 bytes)

The following bugs in omniORB 3.0.2 have been fixed. You can get the fixes in three ways:

  • Update from CVS in the "omni3_develop" branch.
  • Apply this patch to the omniORB 3.0.2 distribution.
  • Download the latest source snapshot. (Note that this is generated nightly, so the latest bugfixes may not appear until tomorrow.)

The bugs pages for earlier versions can be found here:


Summary: Incorrect connection closure on Windows (bug number 16)
Date: Mon Feb 5 12:12:14 GMT 2001
Fixed by: dpg1
Reported by: Victor Joukov
Description: In extremely rare cases, a recv() could be interrupted on Windows, causing a connection closure, rather than the proper retry.

Summary: omniIDL/C++ backend interface inheritance errors (bug number 15)
Date: Sun Jan 28 15:30:10 GMT 2001
Fixed by: djs
Reported by: Gnana
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-12/0157.html
Description: The C++ backend failed to map the names of some interfaces to unambiguous C++ class names in some circumstances. Example IDL:
    interface I{};
    module M{
      interface I : ::I{};
      interface J : I{};
    };
    

Summary: Bug in omniidl C++ back-end with struct member within a union which in turn is within a namespace. Only causes compilation problem with MSVC++. (bug number 14)
Date: Wed Jan 24 13:28:27 GMT 2001
Fixed by: sll
Reported by: Lars Immisch
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2001-01/0145.html
Description: IDL like the following would cause invalid code be generated for MSVC++:
     namespace A {
       union B switch(long) {
         case 0:
              struct C {
                  string op;
              } ex;
         default:
              long digit;
       };
    };
    

Summary: Bug in omniidl C++ back-end with unusual inheritance (bug number 13)
Date: Mon Jan 15 15:49:43 GMT 2001
Fixed by: dpg1
Reported by: Daniel von Tabouillot
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2001-01/0100.html
Description: IDL like the following would cause an internal error in the omniidl C++ back-end:
    interface A;
    typedef A B;
    interface A {};
    interface C : B {};
    

Summary: CORBA::Object::_narrow() does not increment the reference count. (bug number 12)
Date: Mon Dec 11 09:51:35 GMT 2000
Fixed by: dpg1
Reported by: Kevin Bailey
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-12/0048.html

Summary: Invalid string in postinvoke() with long operation names (bug number 11)
Date: Tue Dec 5 11:57:03 GMT 2000
Fixed by: dpg1
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-12/0029.html
Description: If the operation name is longer than 32 characters, postinvoke() would be called with an invalid operation name string.

Summary: Bug with multiply-recursive TypeCode (bug number 10)
Date: Mon Nov 27 18:48:52 GMT 2000
Fixed by: jnw/dpg1
Reported by: Walter Stroebel
Description: A recursive type in which more than one member recursed to the same type could cause an infinite recursion, leading to a stack overflow.

Summary: New platform file for Tru64 5.0 (bug number 9)
Date: Thu Nov 23 11:22:57 GMT 2000
Fixed by: sll
Reported by: [email protected]
Description: Also fixed a problem with omkdepend when compiled with native cc.

Summary: On Digital Unix/Tru64, gethostbyname_r() is not used properly (bug number 8)
Date: Thu Nov 23 11:22:57 GMT 2000
Fixed by: sll
Reported by: Neeraj Bhatia
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-05/0064.html
Description: This bug causes intermittent problems and causes a crash in gethostbyname_r.

Summary: Invalid object references handled incorrectly (bug number 7)
Date: Tue Nov 21 10:46:54 GMT 2000
Fixed by: dpg1
Reported by: Nick Belshaw
Description: An IOR containing no recognised profiles (e.g. from ORBit with default settings) would be treated as nil by string_to_object, and a MARSHAL exception by the unmarshalling code. The correct exception is INV_OBJREF.

Summary: System exceptions not forwarded from incarnate() and preinvoke() (bug number 6)
Date: Mon Nov 13 11:47:35 GMT 2000
Fixed by: djr
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-11/0083.html
Description: System exceptions thrown from a ServantLocator's preinvoke() method, or a ServantActivator's incarnate() method are silently converted into an OBJ_ADAPTER exception. They should be passed on to the client without change.

Summary: Examples fail to build with nmake on Windows 9x (bug number 5)
Date: Tue Nov 7 15:31:24 GMT 2000
Fixed by: dpg1
Description: As explained in 3.0.1's bug 9, some Windows 98 machines (but not all) fail to cope with the pipe between the C pre-processor and omniidl. The work-around is to use the -T flag. The dir.mak files in the examples now use this flag.

Summary: omniidl system dependency clean-up (bug number 4)
Date: Tue Oct 24 10:44:08 BST 2000
Fixed by: dpg1
Description: Not really a bug, but some long-standing ugliness in omniidl's system dependencies has been cleaned up. It's listed here because any code which uses omniidl's C++ interface may need to be slightly modified.

Summary: omniIDL/C++ backend tie template operation mapping error (bug number 3)
Date: Mon Oct 16 18:56:53 BST 2000
Fixed by: djs
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-10/0071.html
Description: The tie template code used the _objref argument mapping rather than the _impl mapping.

Summary: Race condition in POA triggers assertion failure (bug number 2)
Date: Fri Oct 13 09:56:03 BST 2000
Fixed by: djr
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-10/0055.html
Description: There is a race condition in the POA between deactivating an object and it being etherealised, which can trigger an assertion failure (which in turn throws an omniORB::fatalException()).

Summary: C++ back-end claims that it does not support long long (bug number 1)
Date: Fri Oct 6 09:58:55 BST 2000
Fixed by: dpg1
Reported by: Chris Knight
Description: A new check added to the C++ back-end incorrectly reported that long long is not supported, even though it is. Note that long long is not currently supported in Any.


For comments, feedback, etc, please see the 'Keeping in touch' page.
Copyright 2000 - AT&T Laboratories Cambridge