Bug 86359 - /lib/i686 no longer used?
Summary: /lib/i686 no longer used?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
: 86398 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-20 15:32 UTC by Nadav Har'El
Modified: 2007-04-18 16:52 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-10 23:09:24 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:089 0 high SHIPPED_LIVE : Updated glibc packages fix vulnerabilities in RPC XDR decoder 2003-04-10 04:00:00 UTC

Description Nadav Har'El 2003-03-20 15:32:48 UTC
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! :)

Comment 1 Jakub Jelinek 2003-03-20 16:04:20 UTC
Cannot reproduce it.
What exact kernel are you running?
ls -l /lib/i686
strace /bin/echo
rpm -q --qf '%{arch}\n' glibc

Comment 2 Nadav Har'El 2003-03-20 16:10:56 UTC
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




Comment 3 Jakub Jelinek 2003-03-20 16:25:37 UTC
Strange. Can you:
LD_SHOW_AUXV=1 /bin/echo
ldconfig -p | grep libc.so
echo assume kernel $LD_ASSUME_KERNEL

Comment 4 Nadav Har'El 2003-03-20 16:33:34 UTC
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


Comment 5 Jakub Jelinek 2003-03-20 17:34:42 UTC
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.

Comment 6 Nadav Har'El 2003-03-20 21:55:56 UTC
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 :)

Comment 7 Jakub Jelinek 2003-03-24 15:39:30 UTC
*** Bug 86398 has been marked as a duplicate of this bug. ***

Comment 8 Jakub Jelinek 2003-04-10 23:09:24 UTC
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



Note You need to log in before you can comment on or make changes to this bug.