omniORB 3.0.1 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.1 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.1 distribution.
  • Download the latest source snapshot. (Note that this is generated nightly, so the latest bugfixes may not appear until tomorrow.)

The bugs page for earlier versions can be found here:
Summary: Clash with name _T (bug number 14)
Date: Mon Sep 25 11:52:16 BST 2000
Fixed by: dpg1
Reported by: All sorts of people
Description: omniORB used _T as a template class name in various places. This causes problems with standard headers on some platforms, which #define _T. All uses of _T have been changed.
Summary: Workaround for the Sun C++ 5.0 or Forte WS 6.0 exception unwinding bug (bug number 13)
Date: Tue Sep 21 15:13:05 BST 2000
Fixed by: sll
Reported by: Sai-Lai Lo
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-08/0241.html
Description: Sun C++ 5.0 or Forte C++ 6.0 generated code will segv occasionally when concurrent threads throw an exception. The stack trace points to a problem in the exception unwinding. The workaround seems to be to install explicitly an uncaught exception handler.
Summary: C++ backend reversed order of includes in .hh file (bug number 12)
Date: Tue Sep 19 14:50:05 BST 2000
Fixed by: djs
Reported by: NODA Itsuki
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-09/0090.html
Description: If an IDL source file #included <a.idl> and <b.idl> then the resulting header would #include <b.hh> before <a.hh>.
Summary: Bug when assigning a String_var to itself (bug number 11)
Date: Tue Sep 19 10:08:31 BST 2000
Fixed by: dpg1
Reported by: Stefan Engelhardt
Description: Assigning a String_var to itself would incorrectly delete the string contents.
Summary: omniidl/C++ bug with unions with implicit default members (bug number 10)
Date: Wed Sep 13 10:09:43 BST 2000
Fixed by: djs
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-09/0054.html
Description: The generated _d(...) method was incomplete, preventing the discriminant from being changed within the set of legal default values after calling _default() on a union with an implicit default member.
Summary: omniidl produces no useful output on Windows 98 (bug number 9)
Date: Mon Sep 11 15:12:38 BST 2000
Fixed by: dpg1
Reported by: Guangyu Gu, Mark Pumar, others
Description: On some Windows 98 machines, but not others, the C pre-processor output is echoed to the screen, rather than forming the input to omniidl. omniidl therefore fails to generate any code. This fix adds a -T option to omniidl, which uses a temporary file rather than a pipe between the pre-processor and omniidl. It is reported that this works on affected Win98 machines.
Summary: Support for Python 1.6 and 2.0b1 (bug number 8)
Date: Wed Sep 6 12:13:30 BST 2000
Fixed by: dpg1
Description: omniidl was hard-coded to require Python 1.5.2, just in case later versions were incompatible. 1.6 and 2.0b1 are compatible, so they are now supported.
Summary: #includes of iostream.h left in omniORB headers (bug number 7)
Date: Mon Sep 4 10:02:41 BST 2000
Fixed by: dpg1
Reported by: Paul Nader
Description: Several files had #include<iostream.h> left behind from debugging. This causes problems for code which does #include <iostream> without the .h.
Summary: BOA constructor with object key broken (bug number 6)
Date: Wed Aug 30 10:43:34 BST 2000
Fixed by: dpg1
Reported by: Paul Nader
Description: The fix to bug 8 in omniORB 3.0.0 did not actually work.
Summary: omniidl loses all but the first comment with -K (bug number 5)
Date: Fri Aug 25 14:25:20 BST 2000
Fixed by: dpg1
Reported by: Richard Gruet
Description: On some platforms, omniidl -K would lose all but the first comment attached to a node. The code used a construct whose evaluation order is undefined in C++, so it worked with some compilers, but not others.
Summary: MSVC5/6 marshalling multidimensional arrays of basic types (bug number 4)
Date: Wed Aug 23 16:44:36 BST 2000
Fixed by: djs
Reported by: dme
Description: MSVC5/6 fail to resolve the correct operator[] when marshalling a multidimensional array of basic types, only in the return case (not when using an out type)
Summary: "Unexpected" exception at initialization (bug number 3)
Date: Tue Aug 22 15:48:11 BST 2000
Fixed by: sll
Reported by: Chris Newbold
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-08/0066.html
Description: When the port specified via -ORBpoa_iiop_port happens to be in use, an internal omniORB exception is raised by resolve_initial_reference(). Now a system exception CORBA::INITIALIZE is raised instead.
Summary: Missing make rules for GCC on Solaris (bug number 2)
Date: Tue Aug 22 10:59:21 BST 2000
Fixed by: dpg1
Reported by: Mark Borges
Link for this bug: http://www.uk.research.att.com/omniORB/archives/2000-08/0170.html
Description: Make rules for the omniDynamic shared library were missing, so the new libCOS failed to link.
Summary: Typo in omniidl.idltype.Declared.name() (bug number 1)
Date: Mon Aug 21 10:11:51 BST 2000
Fixed by: dpg1
Reported by: Richard Gruet
Description: The name() function of idltype.Declared accidentally returned a list containing a single string rather than just the string itself.

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