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

[Peter Chase]

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?

[Peter Chase]

I am re-posting this because someone at my work who subscribes to this
list said he didn't receive my question and wondered if there might have
been a technical hitch, particularly as it was my first post on this
forum. My apologies if you have already seen this post. Of course, if you
have already seen it, but have time to look again,...

Original Post
--------------------



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?

[Luke Deller]

Hi Peter,

This omniORB error and errno value are what you'd get if you supplied the wrong IP address to -ORBendPoint

Are you certain that you got this IP correct? Is it listed by the command "ifconfig -a"? Can you bind to that address at all, eg with a command like the following?

python -c "import socket; socket.socket().bind(('172.16.153.81',9907))"

Regards,
Luke.
**********************************************************************************************
Important Note
This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Market Technology Limited.

It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system.
IRESS Market Technology Limited does not warrant that the information is free of a virus or any other defect or error.
**********************************************************************************************

[Duncan Grisby]

Post by Peter Chase
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: -
giop:tcp:172.16.153.81:9907

Are you sure that's the right IP address, and that nothing else is
listening on that port? What happens if you don't give an endPoint
option?

What output do you get if you run with -ORBtraceLevel 25?

Cheers,

Duncan.

[Peter Chase]

Post by Duncan Grisby

Post by Peter Chase
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

Post by Duncan Grisby

Post by Peter Chase
POA. Inside OmniORB, it is failing to bind().
Error message from OmniORB: -
giop:tcp:172.16.153.81:9907

Are you sure that's the right IP address, and that nothing else is
listening on that port? What happens if you don't give an endPoint
option?

Yes, that is very definitely the right IP address. We have additionally
tried 127.0.0.1, which fails similarly.

Post by Duncan Grisby
What output do you get if you run with -ORBtraceLevel 25?

Not a lot.

At the moment, there is a possible explanation. The boss's superior
Googling skills found the following article: -

http://www.digitalmars.com/d/archives/digitalmars/D/bugs/Issue_818_New_std.socket.InternetAddress.sin_needs_to_be_properly_initialized_on_OS_X_9912.html

Some quick tests have indicated that our problem is due to this. By
zeroing-out the struct sockaddr_in inside IP4AddrInfo constructor, the
problem seems to go away (in a quick test - to be confirmed). It looks as
if I may need to define HAVE_STRUCT_SOCKADDR_IN_SIN_LEN and
HAVE_STRUCT_SOCKADDR_IN_SIN_ZERO in "omniORB4:CORBA_sysdep_trad.h" for
"__darwin__".

Note that I'm using our own platform file ("uni_macos....mk") because
we're building Universal Binary. Maybe a build done with "configure" would
have detected the need for these symbols.

I shall reply to the thread to let you know whether the above suggested
root cause and fix are correct.

[Peter Chase]

Post by Peter Chase
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

Post by Peter Chase
POA. Inside OmniORB, it is failing to bind().
Error message from OmniORB: -
giop:tcp:172.16.153.81:9907

This seems to be confirmed as due to a need to set some socket-related
preprocessor symbols. I now have the following at line 520 of
"omniORB4:CORBA_sysdep_trad.h"

#elif defined(__darwin__)
# define HAVE_STRTOUQ 1
# define OMNI_SOCKNAME_SIZE_T socklen_t
# define HAVE_STRUCT_SOCKADDR_IN_SIN_ZERO 1
# define HAVE_STRUCT_SOCKADDR_IN_SIN_LEN 1

It's the SOCKADDR ones that are new for this issue.

I don't know whether this problem is specific to our particular build on
Mac OS X, or whether it affects all Mac OS X. We have disabled IPv6 via
compilation option. We have also built Universal Binary, via our own
"*.mk" file; we do not use "configure" on this platform.

[Duncan Grisby]

Post by Peter Chase
This seems to be confirmed as due to a need to set some socket-related
preprocessor symbols. I now have the following at line 520 of
"omniORB4:CORBA_sysdep_trad.h"
#elif defined(__darwin__)
# define HAVE_STRTOUQ 1
# define OMNI_SOCKNAME_SIZE_T socklen_t
# define HAVE_STRUCT_SOCKADDR_IN_SIN_ZERO 1
# define HAVE_STRUCT_SOCKADDR_IN_SIN_LEN 1

Thanks. I've checked in your additions.

Post by Peter Chase
I don't know whether this problem is specific to our particular build on
Mac OS X, or whether it affects all Mac OS X. We have disabled IPv6 via
compilation option. We have also built Universal Binary, via our own
"*.mk" file; we do not use "configure" on this platform.

omniORB definitely works fine on Mac OS X with the autoconf build, so
it's unique to using the old-style configuration.

Cheers,

Duncan.