I didn't see this problem in the database. I installed RH7.0 on my IBM 701CS laptop. Both during install and afterwards, when trying to "startx" I got a Sig11. This machine uses a Chips & Technologies Chip, so I contacted the XFree86 person who maintains this driver. I generated a gdb backtrace for him - he determined that the problem was an attempt to free a NULL pointer in a generic part of the XFree86 code (i.e., not in the driver code). He suggested that I download the XFree86 binaries directly from XFree86.org and install. When I did, the problem disappeared. A subsequent email from another XFree developer stated that he had indeed fixed the bug. It was also stated that the Redhat version of XFree86 is modified from the original XFree86 code, and that you might be interested in the backtrace as well. So, FYI, a complete transcript of the gdb session is shown below.: # gdb XFree86 core GNU gdb 5.0 Copyright 2000 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 `XFree86'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x4007f131 in __kill () from /lib/libc.so.6 (gdb) backtrace #0 0x4007f131 in __kill () from /lib/libc.so.6 #1 0x4007eead in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40080534 in abort () at ../sysdeps/generic/abort.c:88 #3 0x80d5cb0 in GiveUp () #4 0x80d777b in FatalError () #5 0x807f00f in xf86SigHandler () #6 <signal handler called> #7 chunk_free (ar_ptr=0x56e58955, p=0x8178051) at malloc.c:3071 #8 0x400ca5fc in __libc_free (mem=0x8178059) at malloc.c:3043 #9 0x8073684 in xf86FindPrimaryDevice () #10 0x806c2e7 in InitOutput () #11 0x80bfcd2 in main () #12 0x4006e790 in __libc_start_main (main=0x80bfa20 <main>, argc=1, ubp_av=0xbffffab4, init=0x806af68 <_init>, fini=0x8175a0c <_fini>, rtld_fini=0x4000d35c <_dl_fini>, stack_end=0xbffffaac) at ../sysdeps/generic/libc-start.c:111 (gdb) quit
This looks like it might be a glibc issue, reassigning to glibc. If not, whip it right back at me.
This means free memory list corruption in XFree86, which means a bug in XFree86, not in glibc (at least in 99.999% of cases). Some malloc debugging (such as efence or MALLOC_CHECK_ or similar) would tell more. Usually apps either free something twice, or write past or before malloced chunks, etc.
Ok, thanks Jakub. I'll look deeper into the issue once I can successfully reproduce.
You might look at my original posting about this bug - someone in the XFree86 group determined that the bug was indeed an attempt to free a NULL pointer, and that the bug had been fixed in the generic XFree86 code. (Sorry, but I didn't save the email messages, but they should be in the the archives for the XFree86 list around the time of the original bug report. I don't believe the email discussion actually identified the location of the bug, however.) The problem was in the main XFree86 code, not in the specific driver. The fix apparently was applied after RedHat had "frozen" the code for its latest release, or it was in a part of the code that was modified by RedHat. Hope this helps. -Bob Rinker
Yes, it appears this has been fixed as you report above. The latest release at ftp://people.redhat.com/mharris/testing does not appear to have this problem.