[svlug] Debugging memory problems
dfm at area.com
Tue Jan 15 17:55:01 PST 2002
Sanatan Rai wrote:
> I have a simulation that runs quite well on Sun machines running
> Solaris (various). However it seg-faults while reading some data
> files on x86. I had the same problem with Win2000 and g++ and Linux
> (SULinux/RH7.x) + g++, so it seems to me that the problem has
> something to do with the architecture. I am at a loss as to how to
> find the exact problem.
This practically screams "big-endian versus little-endian" at me.
SPARC is big-endian. x86 is little-endian.
If you naively write a multibyte value -- for example, an int -- out
to a file on a SPARC, and then naively attempt to read it back in on
an x86, you will find that its bytes will appear to have been swapped:
the most-significant byte will have traded places with the
least-significant, and the next-most-significant with the
If the value in question is a pointer, array index, or some other kind
of offset into a related structure, then your program will be
attempting to access wildly incorrect areas of memory. That would
account for your seg faults, as well as the fact that you see this
problem irrespective of OS but not of architecture.
One of the standard ways of working around this problem is to use
"network" byte order, which everybody agrees upon, for your data
files. You call "htons" or "htonl" on your data values before writing
them out, and "ntohs" and "ntohls" after reading them in. Sure, those
functions are guaranteed to be no-ops on at least one of the platforms
you care about, but so what? You'll have greatly increased the
portability of both your code and data.
Good luck. I hope this helps.
More information about the svlug