Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-10 23:09:24 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:089 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.