[omniORB] omniORB and gcc-3.0. Don't bother.

[Sai-Lai Lo]

In June I posted this message:

http://www.uk.research.att.com/omniORB/archives/2001-06/0182.html

saying that the only problem I've uncovered with gcc 3.0 and omniORB is the
multiple inheritance bug. That is not true! Thanks to Austin Green to dig
into the details, there is a fundamental bug in the code generated by gcc
3.0 that it is not possible for omniORB to work reliably when compiled with
gcc 3.0.

The symptom is that omniNames hangs when one runs eg3_impl 1 or 2 times.

This is caused by a bug in the code generated by gcc 3.0. A simple test case
is:

----------------------------------
#include <iostream.h>

class A {
public:
  A() {
    cerr << "A()" << endl;
  }

  ~A() {
    cerr << "~A()" << endl;
  }

};

void f() {
  A a;

  try {
    throw long(0);
  }
  catch(int&) {
    cerr << "Got int exception" << endl;
  }
}


int
main(int,char**) {
  try {
    f();
  }
  catch(long& v) {
    cerr << "Got long " << v << endl;
  }
  return 0;
}

-------------
Compile the test code with gcc-3.0 on linux. Execute the program will
produce the following
output:

$ ./testcc
A()
Got long 0


The correct output is:
$ ./testcc
A()
~A()
Got long 0


The missing dtor call is fatal as this means that any resource allocation
will not be released.
This leads to various deadlock within the ORB.

In summary, don't bother using gcc 3.0 until the bugs are fixed.


Regards,

Sai-Lai