segfault with statically linked binaries

entz · 03-28-2012, 11:13 AM

hello,

i'm doing some "from-scratch" work and i ran across an unusual error that says

Code:

unexpected reloc type in static binarySegmentation fault

what exactly does this error mean?

btw this only happens when running statically linked binaries..

cheers

pan64 · 03-28-2012, 12:21 PM

Sorry, but this looks insufficient. Can you please provide a bit more information:
what do you want to try to build, what library causes the problem?
How did you collect the libraries?
There is a thread about a similar issue:
http://www.linuxquestions.org/questi...queeze-847297/
It means you may mismatched 32bit and 64bit libs. Is this your case also?

entz · 03-28-2012, 12:35 PM

Quote:

Originally Posted by pan64

Sorry, but this looks insufficient. Can you please provide a bit more information:
what do you want to try to build?

well i should mention that i get this when running ldconfig from my newly compiled glibc , the strange thing is that i've compiled the same software several times now with the same version , same binutils , gcc and same everything else , which worked fine but now i'm getting this weird glitch apparently out of nothing , and i've absolutely no clue what possibly could have changed since my last compile ....

Quote:

Originally Posted by pan64

what library causes the problem?
How did you collect the libraries?

i don't think that any libraries are causing problems , when i chroot into my "from scratch" distro (not to be confused with LFS) i can compile and run anything i want including statically linked apps , but ldconfig and sln (all binaries that come with glibc) won't work.

i've run some tests so far and strace reveals weird stuff going on when executing ldconfig

Code:

execve("/sbin/ldconfig", ["/sbin/ldconfig"], [/* 84 vars */]) = 0
uname({sys="Linux", node="HOSTNAME", ...}) = 0
open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

worth noting is that ldconfig is not supposed to open "/dev/tty" , i can't explain why it does that! when i compare this to the ldconfig strace from another box i get a completely different "healthy" line of execution..

Quote:

Originally Posted by pan64

There is a thread about a similar issue:
http://www.linuxquestions.org/questi...queeze-847297/

that thread is irrelevant

Quote:

Originally Posted by pan64

It means you may mismatched 32bit and 64bit libs. Is this your case also?

i don't think so , besides "file" tells me that ldconfig is 64-bit statically linked.

pan64 · 03-28-2012, 12:58 PM

sorry, just to be sure:
using chroot will solve your problem, but with your user account you will get this strange message?
I still think you have/use a corrupted/incompatible library. It is not the ldconfig itself, but something behind it. Maybe your /etc/ld.so.conf is corrupted.
Maybe you have a 64bit dynamic library, but you do not have the static counterpart (or that one is a 32bit release).

entz · 03-28-2012, 01:47 PM

Quote:

Originally Posted by pan64

sorry, just to be sure:
using chroot will solve your problem, but with your user account you will get this strange message?

No , segfault happens eitherway and only with ldconfig (and all other statically linked binaries from this glibc build) , ldconfig from the host distro works fine as well as inside the chroot (in case it's copied into the chroot directory replacing the one which segfaults)

Quote:

Originally Posted by pan64

I still think you have/use a corrupted/incompatible library. It is not the ldconfig itself, but something behind it. Maybe your /etc/ld.so.conf is corrupted.

ld.so.conf can't be corrupted because it's a text file , if you mean ld.so.cache well i've deleted that , so that's out of the question.

Quote:

Originally Posted by pan64

Maybe you have a 64bit dynamic library, but you do not have the static counterpart (or that one is a 32bit release).

i think you're confusing things ... if the static library didn't exist then there would not be a statically linked binary to begin with , the fact that it does compile , assemble and then link is proof that all necessary static libraries are there.

not to mention of course that we're talking about a glibc related binary , which is built/linked right after the libc libraries are .
i can't imagine how "foreign" libs could get into the way in such a scenario.

cheers

pan64 · 03-28-2012, 02:19 PM

sorry, but the message in your first post means something like a 32/64 bit mismatch. That may caused easily by reloc/segfault errors. Also using an incompatible lib may cause really stupid error messages (because the system sometimes tries to resolve unconditionally anything). Again, return back to the unexpected reloc type: it means - at least for me - that the relocation was not successful. I agree with you:

Quote:

if the static library didn't exist then there would not be a statically linked binary to begin with , the fact that it does compile , assemble and then link is proof that all necessary static libraries are there

Yes, I'm confused. Maybe your build environment is not OK.

entz · 03-28-2012, 02:36 PM

Quote:

Originally Posted by pan64

Yes, I'm confused. Maybe your build environment is not OK.

well so am i

however i've just made another discovery which is that , if i compile glibc again within the chroot environment (which was created earlier) then ldconfig would run fine.

so it does seem that the host environment is getting sick , anyways i'm planning to replace it once the new one (which i'm building now) gets operational.

anyways , i need to fix the host environment in order to get there , so where should i start?
you mentioned "returning back to the unexpected reloc type" , now that's interesting , what do you exactly mean by that?
as for the 32/64 bit mismatch , well i don't recall deleting any x86_64 libc libaries , and btw i forgot to mention that i can successfully statically build dummy binaries without any problems at runtime
an interesting question , how can i determine which libraries get statically linked into ldconfig ?

cheers

pan64 · 03-29-2012, 02:15 AM

Quote:

Originally Posted by entz

you mentioned "returning back to the unexpected reloc type" , now that's interesting , what do you exactly mean by that?

means only returning back to that message, the possible meaning of it (that was your original question).

Quote:

Originally Posted by entz

an interesting question , how can i determine which libraries get statically linked into ldconfig ?

during the build you can see what is linked into the executable, or you can see the required dynamic libraries with ldd - all the others are statically linked.

Another thing: ldconfig may load libraries on demand, which were not linked to it at all. If this is the case you may have this 32/64 bit mismatch by those libs - or maybe you linked one version of the lib, but used another later.
What about your LD_LIBRARY_PATH? Is this ok, or contains something "strange"?

Quote:

i can compile and run anything i want including statically linked apps , but ldconfig and sln (all binaries that come with glibc) won't work.

maybe you have two different gcc runtime systems? one was coming with the os and another one was used in your builds...

maybe a full strace log will say more...

Valery Reznic · 03-29-2012, 08:09 AM

Quote:

Originally Posted by entz

hello,

i'm doing some "from-scratch" work and i ran across an unusual error that says

Code:

unexpected reloc type in static binarySegmentation fault

what exactly does this error mean?

btw this only happens when running statically linked binaries..

cheers

Does segfault happened when you run executable om the same box where you build it or on another one?
If another, do they have different glibc versions?

knudfl · 03-31-2012, 05:34 AM

May be the buggy glibc-2.15 is used.

There may be a fix available http://sourceware.org/bugzilla/show_bug.cgi?id=13580

( Ref. http://www.linuxquestions.org/questi...rouble-936592/ )

entz · 03-31-2012, 10:37 AM

Quote:

Originally Posted by knudfl

May be the buggy glibc-2.15 is used.

There may be a fix available http://sourceware.org/bugzilla/show_bug.cgi?id=13580

( Ref. http://www.linuxquestions.org/questi...rouble-936592/ )

no it's not...

alright folks , thanks to everybody who so far tried to help out

i decided to go for the simple and easy way which is leaving everything as is until i refresh my box with a new distro
(which already is due for a long time)

cheers