The following bugs in omniORB 3.0.2 have been fixed. You can get the fixes in three ways:
|
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: |
dek_ml@konerding |
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. |
|