[omniORB] OmniORB 4.1 on Mac OS X - problem with bind()

Peter Chase peter.chase at globalgraphics.com
Thu Jun 7 16:01:05 BST 2007


We are transitioning from OmniORB 3.0.4 to 4.1 are having problems 
starting OmniORB 4.1 on Mac OS X. It starts OK on Windows (XP and Vista 
tested) and Linux.

The problem occurs after ORB initialisation, when we try to find the root 
POA. Inside OmniORB, it is failing to bind().

Error message from OmniORB: -
        Error: Unable to create an endpoint of this description: 
giop:tcp:172.16.153.81:9907

Stack trace just after bind() has failed: -
#0  omni::tcpEndpoint::Bind (this=0x3548c70) at ./tcp/tcpEndpoint.cc:425
#1  0x0408ae50 in omni::giopServer::instantiate (this=0x3548360, 
uri=0x3548440 "giop:tcp:172.16.153.81:9907", no_publish=false, 
listening_endpoints=@0xbfffd9d8) at giopServer.cc:288
#2  0x040399e0 in omni::instantiate_endpoint (uri=0x3548440 
"giop:tcp:172.16.153.81:9907", no_publish=false, 
listening_endpoints=@0xbfffd9d8) at objectAdapter.cc:254
#3  0x0403a3a8 in omni::omniObjAdapter::initialise () at 
objectAdapter.cc:403
#4  0x0405d334 in initialise_poa () at poa.cc:2464
#5  0x0405d96c in omni::omniOrbPOA::rootPOA (init_if_none=1) at 
poa.cc:2499
#6  0x0405da10 in omni::resolveRootPOAFn () at poa.cc:4144
#7  0x0402ac44 in omni::resolvePseudo (id=0x2f1a6c "RootPOA", cycles=0) at 
initRefs.cc:440
#8  0x0402d224 in omni::omniInitialReferences::resolve (id=0x2f1a6c 
"RootPOA", cycles=0) at initRefs.cc:686
#9  0x04012060 in omniOrbORB::resolve_initial_references (this=0x35487a0, 
id=0x2f1a6c "RootPOA") at corbaOrb.cc:778
#10 0x00017e64 in ORBImpl::activate_orb (persistent_poa=1, ins_poa=0) at 
./HQN_CPP_CORBA/src/orb_impl.cpp:411

The global "errno" is 49, which is EADDRNOTAVAIL (address not available).

Due to problems on Vista, we have disabled IPv6 for the moment. We did 
this with DIR_CPPFLAGS += -DOMNI_DISABLE_IPV6 in 
src:lib:omniORB:orbcore:dir.mk .

We are explicitly setting the endpoint, via "-ORBendPoint", because we 
need to control how the host name gets stored in IORs, as they will go 
persistently into a Name Service. In OmniORB 3.0.4, we used 
"-ORBpoa_iiop_name_port". The hope is that these are equivalent. Are they?

The problem occurs if the value of "-ORBendPoint" is the machine's IP (v4) 
address. It does *not* occur if the value is "localhost".

I'm out of ideas. Anyone got any suggestions?



More information about the omniORB-list mailing list