Bug 58308

Works just fine for me.  Why are you updating to i386 glibc BTW? Were you using
i686 one previously?

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?

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.

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.

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).

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!

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?

Created attachment 42455 [details]
strace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel

Created attachment 42456 [details]
ltrace from "loadkeys us" with glibc 2.2.90 and 2.2.x kernel

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.

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?

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.

This has been fixed in gcc-3.1-0.18 and likely glibc-2.2.90-4.