Bug 58308 - Rawhide glibc is hosed
Rawhide glibc is hosed
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: glibc (Show other bugs)
1.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-13 21:52 EST by Jonathan Kamens
Modified: 2016-11-24 10:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-05 11:59:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel (4.61 KB, text/plain)
2002-01-14 21:41 EST, Jonathan Kamens
no flags Details
ltrace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel (12.97 KB, text/plain)
2002-01-14 21:42 EST, Jonathan Kamens
no flags Details

  None (edit)
Description Jonathan Kamens 2002-01-13 21:52:20 EST
I had these installed:

glibc-common-2.2.4-20
glibc-2.2.4-20
glibc-profile-2.2.4-20
glibc-devel-2.2.4-20

I attempted to upgrade to these:

glibc-2.2.90-3.i386.rpm         glibc-debug-static-2.2.90-3.i386.rpm
glibc-common-2.2.90-3.i386.rpm  glibc-devel-2.2.90-3.i386.rpm
glibc-debug-2.2.90-3.i686.rpm   glibc-profile-2.2.90-3.i386.rpm

When I rebooted after doing so, loadkeys segfaulted while loading my key table,
depmod segfaulted while trying to update kernel dependencies, and swapon hung. 
Reverting to the previous glibc packages made the problems go away.

Yuck.
Comment 1 Jakub Jelinek 2002-01-14 07:00:10 EST
Works just fine for me.  Why are you updating to i386 glibc BTW? Were you using
i686 one previously?
Comment 2 Jonathan Kamens 2002-01-14 10:31:51 EST
I was upgrading to the i386 package because the script that I use to tell me
when new Rawhide packages are available wasn't properly handling the case of a
package with support for multiple architectures.  In any case, I tried the i686
package, and it has the same problem.  Additional details....

* Here's what gdb says when I run it on loadkeys and the core file after the
coredump:

GNU gdb Red Hat Linux (5.1-2)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `loadkeys us'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x400de422 in versionsort () from /lib/libc.so.6
(gdb) where
#0  0x400de422 in versionsort () from /lib/libc.so.6
#1  0x400dde0c in readdir () from /lib/libc.so.6
#2  0x0804e997 in strcpy ()
#3  0x0804e6ef in strcpy ()
#4  0x0804e6ef in strcpy ()
#5  0x0804e6ef in strcpy ()
#6  0x0804ed42 in strcpy ()
#7  0x0804d62b in strcpy ()
#8  0x0804a330 in strcpy ()
#9  0x08049f73 in strcpy ()
#10 0x40041158 in __libc_start_main () from /lib/libc.so.6
(gdb) 

I suspect that the stack above is not completely "honest", but the "versionsort"
part of it appears to be consistent -- I see that in the strack traces of all
the processes that are coredumping.

* I tried to use glibc-debug to debug this further, but I was unable to get the
system to recognize that there are valid shared libraries in /usr/lib/debug. 
Setting LD_LIBRARY_PATH to /usr/lib/debug had no effect whatsoever.  Replacing
/lib/libc-2.2.90.so with /usr/lib/debug/libc-2.2.90.so didn't work either -- I
got "sh: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory" when trying to run anything afterwards. 
Are you sure the libraries in the glibc-debug package are OK?
Comment 3 Jakub Jelinek 2002-01-14 10:52:09 EST
This is very weird at least.
/usr/lib/debug works just fine for me:
$ gdb /tmp/test
GNU gdb 2001-11-07-cvs
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) set env LD_LIBRARY_PATH=/usr/lib/debug/
(gdb) b main
Breakpoint 1 at 0x8048409: file /tmp/test.c, line 17.
(gdb) r
Starting program: /tmp/test

Breakpoint 1, main () at /tmp/test.c:17
17        exit (0);
(gdb) l strcpy
26      ../sysdeps/generic/strcpy.c: No such file or directory.
        in ../sysdeps/generic/strcpy.c
(gdb) set env LD_LIBRARY_PATH=
Setting environment variable "LD_LIBRARY_PATH" to null value.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/test

Breakpoint 1, main () at /tmp/test.c:17
17        exit (0);
(gdb) l strcpy
No line number known for strcpy.
(gdb) quit
The program is running.  Exit anyway? (y or n) y

(as you can see, if I use /usr/lib/debug libraries, they have debugging info,
if not, there is no debugging info for glibc).

The above details are with glibc-2.2.90-3.i386.rpm, right?
Otherwise the library in question would be /lib/i686/libc.so.6, not /lib/libc.so.6.
versionsort is never called from readdir, so the backtrace is obviously bogus.
Comment 4 Jonathan Kamens 2002-01-14 10:58:28 EST
I wonder if perhaps you have a newer version of ld.so and there's an
incompatibility.  I have ld.so-1.9.5-13.

The above details were with the i686 package, not the i386 package.  note that
it installs files both in /lib and /lib/i686.  Note, furthermore, that when I
ran "ldd" on a random binary after installing the i686 package, it listed the
libc in /lib, not the one in /lib/i686.
Comment 5 Jakub Jelinek 2002-01-14 11:07:06 EST
The dynamic linker you use is in glibc-2.2.90* rpm, ld.so-1.9.5-13 is just
for libc 5 programs.
By any chance, are you running a 2.2 kernel? glibc-debug is not compatible with
that (and /lib/i686/libc.so.6 is neither).
Comment 6 Jonathan Kamens 2002-01-14 11:09:38 EST
Yes, I'm using a 2.2 kernel.

I really, really hope that you're not planning on releasing a glibc version that
isn't compatible with 2.2 kernels.  Surely there is a way to make it backward
compatible.  There are people, including me, who *can't* use 2.4.x kernels
because they f**k up our IDE drives.  I'd love to see this fixed, and I've been
trying to help the people who know something about kernel IDE support to fix it,
but in the meantime, please don't make it impossible for people like me to keep
our systems up-to-date by releasing a glibc that won't work with 2.2!
Comment 7 Jakub Jelinek 2002-01-14 11:22:10 EST
Well, nothing changed in this regard since 7.1 days:
in glibc-2.2.4-NN if you install i686.rpm, you get both /lib/libc.so.6 and
/lib/i686/libc.so.6. The former works with 2.2 kernels and was stripped,
the latter works with 2.4 kernels only and was not stripped.
In glibc-2.2.90 currently just /lib/i686/libc.so.6 is stripped too (but
using strip -g, not strip, so .symtab/.strtab are kept) and the unstripped
library is in /usr/lib/debug.

Now, to back to the original issue:
can you do strace and ltrace of loadkeys to see what is it really doing?
Comment 8 Jonathan Kamens 2002-01-14 21:41:48 EST
Created attachment 42455 [details]
strace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel
Comment 9 Jonathan Kamens 2002-01-14 21:42:18 EST
Created attachment 42456 [details]
ltrace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel
Comment 10 Jonathan Kamens 2002-01-14 21:43:27 EST
It looks like you were right -- I don't have this problem when I run the new
glibc with kernel 2.4.x, so it is a kernel incompatibility issue.  But note that
I *also* don't have the problem with 2.2.x with glibc-2.2.4-20.i686.rpm
installed, so I'm not convinced that you're right that there have been
incompatibilities since 7.1.  I think this is new and needs to be fixed.
Comment 11 Jakub Jelinek 2002-01-15 06:34:19 EST
As I said, I'm not aware of any change in readdir/getdents which might cause
this.  Well, it might be that this function is miscompiled with gcc-3.1.

Can you please try:
#include <dirent.h>
#include <stdlib.h>

int main (void)
{
  DIR *dir = opendir("/lib/kbd/keymaps");
  if (dir == NULL)
    exit (1);
  readdir (dir);
  exit (0);
}

if it crashes too?
If yes, does the same thing statically linked crash as well?
Comment 12 Jakub Jelinek 2002-01-15 07:34:30 EST
Ok, I checked __getdents disassembly carefully and it is a reload bug, which
Richard Henderson fixed 5 days ago:
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00780.html
I'll put this into gcc soonish and once glibc will be rebuilt with that, it
should work fine again.
Comment 13 Jakub Jelinek 2003-08-05 11:59:51 EDT
This has been fixed in gcc-3.1-0.18 and likely glibc-2.2.90-4.

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