Bug 21595 - XFree Sig11s upon startup
Summary: XFree Sig11s upon startup
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-01 19:20 UTC by Bob Rinker
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-22 23:36:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bob Rinker 2000-12-01 19:20:42 UTC
I didn't see this problem in the database. I installed RH7.0 on my IBM
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
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
welcome to change it and/or distribute copies of it under certain
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
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

Comment 1 Mike A. Harris 2001-03-17 20:48:22 UTC
This looks like it might be a glibc issue, reassigning to glibc.  If
not, whip it right back at me.

Comment 2 Jakub Jelinek 2001-03-22 15:52:48 UTC
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.

Comment 3 Mike A. Harris 2001-03-22 20:08:11 UTC
Ok, thanks Jakub.  I'll look deeper into the issue once I can successfully

Comment 4 Bob Rinker 2001-03-22 23:36:11 UTC
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

Comment 5 Mike A. Harris 2001-05-15 09:23:15 UTC
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.

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