Statically-linked binary SegFaults - Linux

This is a discussion on Statically-linked binary SegFaults - Linux ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Statically-linked binary SegFaults

  1. Statically-linked binary SegFaults

    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.


  2. Re: Statically-linked binary SegFaults


    "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.




  3. Re: Statically-linked binary SegFaults

    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)

+ Reply to Thread