[omniORB] Re: At wits end - SEGFAULT on RH 8, runs fine on RH 6.2

Mike Mascari mascarm at mascari.com
Fri May 23 05:38:50 BST 2003


Mike Mascari wrote:

> Hello.
> 
> I have a server application which builds on both RedHat 6.2 and RedHat
> 8.0. The server application runs fine under 6.2, but causes a
> segmentation fault on 8.0. Under 8.0 it starts up fine, invokes a
> method to create a session object on an object factory fine, and then
> causes a segmentation fault on the first method invoked on the
> resultant session object, regardless of what method is invoked.

I figured it out. It was broken code on my part. But now I'm not sure
why it worked on RedHat 6.2?? I have IDL which looks like this:

----

struct Person {
 string lastname;
 string firstname;
};

typedef sequence<Person> Persons;

...

Persons getPersons();

----

I then derive a C++ class from the IDL-generated Persons class and
another class which provides database services (in fact, the IDL and
C++ class are generated from the database schema):

----

class IPersons : public Persons, public DBase {

public:

 IPersons();
 virtual ~IPersons();

public:

 int fetchAllPersons();

};

Finally, in the method getPersons() I *did* something like:

Version #1:
----------

Persons *MyInterface::getPersons() {

 IPersons *persons = new IPersons();

 persons->fetchAllPersons();
 return persons;

}

Now, if the C++ mapping for unbounded sequences generated a virtual
destructor, or there was a virtual destructor anywhere in the
inheritance hierarchy below the derived class, everything would have
been right with the world. But it doesn't, which broke on RedHat 8.0.
On RedHat 6.2, however, it worked (and works) fine. Unfortunately, I
now have to change the code to:

Version #2:
----------

Persons *MyInterface::getPersons() {

 IPersons persons;

 persons.fetchAllPersons();
 return new Persons(persons);

}

but that causes a deep copy to take place that I was trying to avoid.
So...

A) Why does Version #1 above work under RedHat 6.2?

B) Is there a way I can derive a class from the IDL generated classes
for unbounded sequences and return the sequences as results without a
deep copy taking place?

Thanks for any tips,

Mike Mascari
mascarm at mascari.com











> 
> The server code shared between the two is exactly the same:
> 
> Good:
> -----
> RedHat 6.2
> egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> kernel 2.2.19-6.2.15
> omniORB 4.0.1
> 
> Bad:
> ---
> RedHat 8.0 with all packages up2date except kernel
> stock gcc 3.2 20020903
> kernel 2.4.18-14
> omniORB 4.0.1
> 
> The server always dies in sendChunk:
> 
> omniORB: inputMessage: from giop:tcp:192.168.2.1:2775 76 bytes
> omniORB:
> 4749 4f50 0102 0100 4000 0000 0800 0000 GIOP.... at .......
> 0300 0000 0000 0000 1400 0000 ff64 6261 .............dba
> 7365 fe3a 48cd 3e01 0014 5700 0000 0000 se.:H.>...W.....
> 0c00 0000 6765 7441 6363 6f75 6e74 7300 ....getAccounts.
> 0000 0000 0c00 0000 0200 0000           ............
> omniORB: sendChunk: to giop:tcp:192.168.2.1:2775 323 bytes
> omniORB:
> 4749 4f50 0102 0101 3701 0000 0800 0000 GIOP....7.......
> 0000 0000 0000 0000 0400 0000 4944 4c3a ............IDL:
> 6b22 062a 0100 0000 0ffc 052a 0100 0000 k".*.......*....
> 0a00 0000 496e 7665 6e74 6f72 7900 0000 ....Inventory...
> 1100 0000 4974 656d 7320 666f 7220 5265 ....Items for Re
> 7361 6c65 0063 6172 d71f 062a 0100 0000 sale.car...*....
> 0ffc 052a 0100 0000 1900 0000 4f66 6669 ...*........Offi
> 6365 2026 2041 646d 696e 2e20 5375 7070 ce & Admin. Supp
> 6c69 6573 0000 0000 2500 0000 416c 6c20 lies....%...All
> 4f66 6669 6365 2049 7465 6d73 204c 696b Office Items Lik
> 6520 5065 6e73 2c20 5061 7065 722e 2e2e e Pens, Paper...
> 0000 0000 0800 0000 de1f 062a 0100 0000 ...........*....
> 0ffc 052a 0100 0000 1800 0000 5365 7276 ...*........Serv
> 6963 6520 4365 6e74 6572 2053 7570 706c ice Center Suppl
> 6965 7300 2000 0000 4269 7473 2c20 5363 ies. ...Bits, Sc
> 7265 7764 7269 7665 7273 2c20 436c 6561 rewdrivers, Clea
> 6e65 7273 2e2e 2e00 1bfc 052a 0100 0000 ners.......*....
> 0ffc 052a 0100 0000 0900 0000 5375 7070 ...*........Supp
> 6c69 6573 0000 0000 1700 0000 4d69 7363 lies........Misc
> 656c 6c61 6e65 6f75 7320 7375 7070 6c69 ellaneous suppli
> 6573 00                                 es.
> Segmentation fault
> 
> I've tried everything I can think of in the server code:
> 
> 1) Commenting out any pthread code
> 2) Commenting out an embedded python interpreter
> 3) Disabling the SSL endpoint
> 4) Disabling the TCP endpoint
> 5) Starting the server with LANG unset
> 6) Starting the server with LANG=C
> 7) Rebuilding and installing omniORB 4.0.1
> 8) Building code without any optimization
> 9) Invoking different methods on the session object
> 
> Any clues? I don't know why the factory object, which resides in the
> RootPOA works fine, but any method invocation on the session object,
> created by the factory but residing in a differnt POA should die. And
> why it works flawlessly on RedHat 6.2 by segfaults every time on 8.0.
> 
> Mike Mascari
> mascarm at mascari.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 





More information about the omniORB-list mailing list