"David Douthitt" wrote in message
> I have a binary statically linked application that was compiled
> against Red Hat 7.3 (presumably glibc 2.2.5). The application
> SegFaults when run in a Red Hat Advanced Server environment -
> with glibc 2.3.2.
>
We can only deal with language issues here.
If a commercial library segfaults then the problem is probably in your own
code - most likely you are passing a bad pointer, though undefined behaviour
anywhere in your program can sometimes cause a fault in a seemingly
unrelated part.
Try to comment out code until you have a minimal program that exhibits the
problem. If this doesn't lead you to the answer then try posting here, but
as I say we can't deal with UNIX internals but only tell you whether your C
is or is not Ok.

David Douthitt said the following, on 05/20/04 15:40:
> I have a binary statically linked application that was compiled against
> Red Hat 7.3 (presumably glibc 2.2.5). The application SegFaults when
> run in a Red Hat Advanced Server environment - with glibc 2.3.2.
>
> I had another binary (Samhain - to which I have source!) which had the
> same problem and exhibited the same strace. After a recompile, the
> newly compiled static binary worked fine.
>
> Why is this? The first binary I don't have source for and need to make
> my case - and I'm curious besides. My initial response is "it shouldn't
> matter what glibc is, it's statically linked." This appears to be
> wrong. Both binaries made open/close calls to ld-linux.so.2,
> libnss_files.so.2, /lib/tls/libc.so.6, and others. The segfault occurs
> right after ld-linux.so.2 is opened, read, and closed.
>

I think you will be told that this is off-topic in comp.lang.c -- which
it is.

Here are my guesses, in decreasing order of probability (also by my guess!):

1. There is a bug in your program(s), possibly associated with a
garbage pointer, or use of a pointer after free(), which you got away
with in the older environment, but which causes a problem in the new.
This probably would be something associated with a system call, not with
'libc' directly, since you say that the binary is statically linked --
but keep reading.

2. There is something in your program that depends on some part of the
standard or system library (including the required headers), and that
part has changed.

3. There is a new bug that has been introduced into the system
libraries/headers you use.

4. Were the statically linked binaries compiled on the same machine
that you are trying to run them on? There could be subtle changes in
things like and that could mess things up.
Architecture differences (e.g., alignment requirements in structures)
could make trouble.

Also, you don't say, but are these tests being run on identical hardware?

I suggest taking the program for which you have the source, and
compiling it against both environments with all debugging options turned
on, and then running it under the debugger, to try to pinpoint exactly
where the failure occurs.

--
Rich Gibbs
rgibbs@alumni.princeton.edu
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." (Richard Feynman)