Reputation: 51
I'm working on legacy product that uses CORBA. We're looking to support omniiORB as another vendor. I ran into one of our tests seg faulting, and I'm trying to understand if we've been doing something wrong that just happened to work with other vendors, or if there's a bug with omniiORB.
I tested with the version of omniiORB that comes in the Red Hat EPEL (4.2.0). I also downloaded and build the latest version, 4.2.3, and still saw the error.
Below is a test case that I think demonstrates the behavior I'm seeing in our code.
#include <omniORB4/CORBA.h>
//#include "typedefs.hh"
#include <iostream>
// only happens with string types.
// primitive CORBA types and user-defined types don't cause the error
int main() {
CORBA::Any any1;
any1 <<= "Hello";
CORBA::Any any2;
any2 = any1; // copy the any, seg fault in omniiorb
// any2 <<= any1; // any inside any, also seg faults
// CORBA::Any any2(any1); // copy constructor, also seg faults
return 0;
}
I know extracting to a generated smart pointer causes issues since the any should keep ownership. But in the case of copying an Any, isn't it supposed to do a deep copy? What am I missing here?
I have another short example that is closer to what our legacy code does that involves a simple IDL if this example is deemed unrepresentative.
The gist of what the legacy code does is copy properties that use an any for the value, so it can be anything. We haven't seen any issues in the past with Visibroker or ACE+TAO.
Upvotes: 1
Views: 230
Reputation: 51
The problem was on our side and its because we were not initializing the ORB runtime through CORBA::ORB_init().
So the example described in the question is invalid and should be:
#include <omniORB4/CORBA.h>
#include "typedefs.hh"
#include <iostream>
// only happens with string types.
// primitive CORBA types and user-defined types don't cause the error
int main(int argc, char*argv[]) {
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "omniORB4");
CORBA::Any any1;
any1 <<= "Hello";
CORBA::Any any2;
any2 = any1;
return 0;
}
Most of our CORBA code does initialize the ORB runtime, but the test I encountered was a unit test that dealt with translating and copying different CORBA types. We assumed the initialization was only necessary when making network calls, rather than being required before ANY CORBA-related calls.
The test code happened to work with Orbix, Visibroker, and ACE+TAO since in those implementations it didn't matter. It failed in omniiORB because some of native codeset internal implementation details (and other things) aren't initialized (they're null) until ORB_init() is called and this caused the seg fault.
Upvotes: 2