Hide Forgot
After upgrading my Redhat 8.0 to glibc-2.3.2-4.80, a program I am writing stopped working (segmentation violation on malloc()). Unfortunately, I could not isolate this problem yet, but while researching it I found another very strange thing, looks like a bug that I can't explain in the new glibc: When I do "ldd /bin/ls" (for example) on an original Redhat 8.0 I get: .. libc.so.6 => /lib/i686/libc.so.6 (0x42000000) .. I.e., the libc is taken from the /lib/i686 directory. But when I do that with the upgraded glibc, I get: libc.so.6 => /lib/libc.so.6 (0x40033000) Note /lib, not /lib/i686, is used. I doubt this is what cause my segfault, but I think its a bug nontheless - I installed the i686 RPMs because I wanted them to be used! :)
Cannot reproduce it. What exact kernel are you running? ls -l /lib/i686 strace /bin/echo rpm -q --qf '%{arch}\n' glibc
I tried this on two different computers (upgraded seperately) and I got the same results. Here is the results on one of them, "flower": $ uname -a Linux flower 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686 i386 GNU/Linux $ ls -l /lib/i686 total 1684 -rwxr-xr-x 1 root root 1448819 Mar 19 14:45 libc-2.3.2.so lrwxrwxrwx 1 root root 13 Mar 20 14:30 libc.so.6 -> libc-2.3.2.so -rwxr-xr-x 1 root root 171281 Mar 19 14:45 libm-2.3.2.so lrwxrwxrwx 1 root root 13 Mar 20 14:30 libm.so.6 -> libm-2.3.2.so -rwxr-xr-x 1 root root 87941 Mar 19 14:45 libpthread-0.10.so lrwxrwxrwx 1 root root 18 Mar 20 14:30 libpthread.so.0 -> libpthread-0.10.so $ strace /bin/echo execve("/bin/echo", ["/bin/echo"], [/* 13 vars */]) = 0 uname({sys="Linux", node="flower", ...}) = 0 brk(0) = 0x804bb08 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=78781, ...}) = 0 old_mmap(NULL, 78781, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300Y\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1292588, ...}) = 0 old_mmap(NULL, 1298244, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000 old_mmap(0x4015e000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x136000) = 0x4015e000 old_mmap(0x40163000, 8004, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40163000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40165000 munmap(0x40014000, 78781) = 0 brk(0) = 0x804bb08 brk(0x804cb08) = 0x804cb08 brk(0) = 0x804cb08 brk(0x804d000) = 0x804d000 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 write(1, "\n", 1 ) = 1 munmap(0x40014000, 4096) = 0 _exit(0) = ? $ rpm -q --qf '%{arch}\n' glibc i686
Strange. Can you: LD_SHOW_AUXV=1 /bin/echo ldconfig -p | grep libc.so echo assume kernel $LD_ASSUME_KERNEL
Sure. $ LD_SHOW_AUXV=1 /bin/echo AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x8048034 AT_PHENT: 32 AT_PHNUM: 6 AT_BASE: 0x40000000 AT_FLAGS: 0x0 AT_ENTRY: 0x8048a88 AT_UID: 502 AT_EUID: 502 AT_GID: 501 AT_EGID: 501 AT_PLATFORM: $ /sbin/ldconfig -p | grep libc.so libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6 libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6 $ echo assume kernel $LD_ASSUME_KERNEL assume kernel
AT_PLATFORM: This is the problem. It should print AT_PLATFORM: i686 I checked ld-linux.so.2 under debugger and it is the kernel which is passing bogus AT_PLATFORM to the userland, reassigning to kernel.
I'd like to comment that on my home machine, another Redhat 8.0 but slightly less updated with all the latest errata (running kernel 2.4.18-24.8.0 and the original glibc-2.2.93-5), when I run $ LD_SHOW_AUXV=1 /bin/echo I also get AT_PLATFORM: but still, $ ldd /bin/echo libc.so.6 => /lib/i686/libc.so.6 (0x42000000) So either the correct linking has nothing to do with this AT_PLATFORM, or, alternatively, the old glibc.2.2.93-5 ignored this parameter and the new glibc.2.3 now (correctly?) makes use of it. Good luck fixing this bug :)
*** Bug 86398 has been marked as a duplicate of this bug. ***
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-089.html