[omniORB] Re: Endian problems

[Patrick Hartling]

[...]

If the client tries to connect to the server using a stringified
object reference, I get a SequenceIsTooLong marshaling exception from
within IOP::IOR::unmarshaltype_id(). Tracing into it, I find that the
sequence length is supposed to be 32, but the byte order does not get
swapped correctly, thus causing omniORB to think that the sequence is
supposed to be much, much longer. This happens when the client is big
endian and the server is little endian and vice versa. If the
endianness matches for both machines, then there are no problems.

Byte-swapping certainly normally works. I've tried experiments with a
Sparc machine talking to an x86 machine, and it works fine. Whatever is
going wrong is more subtle than simply that it doesn't do the
byteswapping. What kinds of machines are you using, and how did you
build omniORB for them?

I see the problems when trying to connect between my PowerBook G4 and
both of my desktop machines. The PowerBook runs Mac OS X 10.4.7. One
desktop machine is an x86 running Windows XP and Fedora Core 5. The
other is an x86_64 machine running Red Hat Enterprise Linux 4 x86_64
with all the latest updates.

For Mac OS X and Linux, I use the configure-based build and do not
give it any special options other than an installation prefix. For
Windows, I use the older build system that involves editing
config/config.mk.

Could it perhaps be that on one of the machines
the build system thought it was little endian but it's actually
big-endian, or vice-versa? That would mean it didn't swap when it was
meant to.

Yes, that is certainly possible. AFAICT, omniORB correctly determines
the endianness of the little endian machines. I came to that
conclusion while tracing through the code executing on the x86_64
machine and looking at the state of variables related to byte
swapping. I have not done the same sort of examination on the PowerPC
machine. The configure script for omniORB 4.0.7 reports the correct
endianness, and acconfig.h defines WORDS_BIGENDIAN correctly. Is there
anywhere else I should look?

-Patrick

[Duncan Grisby]

Post by Patrick Hartling
Yes, that is certainly possible. AFAICT, omniORB correctly determines
the endianness of the little endian machines. I came to that
conclusion while tracing through the code executing on the x86_64
machine and looking at the state of variables related to byte
swapping. I have not done the same sort of examination on the PowerPC
machine. The configure script for omniORB 4.0.7 reports the correct
endianness, and acconfig.h defines WORDS_BIGENDIAN correctly. Is there
anywhere else I should look?

That really ought to be sufficient. Can you run both client and server
with -ORBtraceLevel 40 between the machines where it fails. That will
show complete GIOP traces so we can see which machine is confused about
its endianness.

Cheers,

Duncan.

[Patrick Hartling]

Post by Duncan Grisby

Post by Patrick Hartling
Yes, that is certainly possible. AFAICT, omniORB correctly determines
the endianness of the little endian machines. I came to that
conclusion while tracing through the code executing on the x86_64
machine and looking at the state of variables related to byte
swapping. I have not done the same sort of examination on the PowerPC
machine. The configure script for omniORB 4.0.7 reports the correct
endianness, and acconfig.h defines WORDS_BIGENDIAN correctly. Is there
anywhere else I should look?

That really ought to be sufficient. Can you run both client and server
with -ORBtraceLevel 40 between the machines where it fails. That will
show complete GIOP traces so we can see which machine is confused about
its endianness.

I tracked down what I was doing wrong, and this (along with my
original message about _narrow() hanging) is a result of operator
error. I forgot that I had coerced the omniORB build to create
universal binaries on Mac OS X. By repeating that process, I saw where
the configure script was reporting that the host computer is not big
endian. What I did when I ran configure was to set the following
environment variables thusly:

CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"
CXXFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk"

I did not realize at the time that that would interfere with the
build's detection of endianness.

I think that if I do two separate builds for PowerPC and i386 and then
combine the binaries using Apple's lipo tool, I will be able to get
universal binaries without the endian confusion. Certainly my
PowerPC-only build of omniORB 4.0.7 is now behaving correctly. Sorry
for the confusion.

-Patrick