Bug 37420

Summary:	2.15.0: Heap corruption causing X deadlock on logout
Product:	xorg	Reporter:	Ian Pilcher <arequipeno>
Component:	Driver/intel	Assignee:	Chris Wilson <chris>
Status:	RESOLVED NOTABUG	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	CC:	keithp
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
See Also:	https://bugzilla.redhat.com/show_bug.cgi?id=705652
Whiteboard:
i915 platform:		i915 features:

Description Ian Pilcher 2011-05-20 14:05:24 UTC

Copied from https://bugzilla.redhat.com/show_bug.cgi?id=705652:

Ian Pilcher 2011-05-17 20:36:44 EDT

Description of problem:
After updating to xorg-x11-drv-intel-2.15.0-3.fc15, I get a hard X hang
every time I log out.  The screen is black, with the mouse pointer visible
but immobile, and the system doesn't respond to any keyboard combination;
the only way to recover the system is to ssh in, kill -9 the X server, and
reboot.

Attaching to the X server with gdb shows that it has deadlocked trying to
report a "corrupted double-linked list":

#0  __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:100
#1  0x00007fb07f8c7c11 in _L_lock_10461 () at malloc.c:6486
#2  0x00007fb07f8c59d7 in __libc_malloc (bytes=140396034138592) at
malloc.c:3657
#3  0x00007fb07f8bb35d in __libc_message (do_abort=2, 
    fmt=0x7fb07f9a6fb8 "*** glibc detected *** %s: %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:137
#4  0x00007fb07f8c196a in malloc_printerr (action=3, 
    str=0x7fb07f9a3f92 "corrupted double-linked list", ptr=<optimized out>) at
malloc.c:6283
#5  0x00007fb07f8c1d48 in malloc_consolidate (av=0x7fb07fbe21e0) at
malloc.c:5161
#6  0x00007fb07f8c2669 in malloc_consolidate (av=0x7fb07fbe21e0) at
malloc.c:5115
#7  _int_free (av=0x7fb07fbe21e0, p=<optimized out>, have_lock=0) at
malloc.c:5034
#8  0x000000351360c01f in FontFileFreeDir (dir=0x1fef3d0) at fontdir.c:166
#9  0x000000351360ce18 in FontFileFreeFPE (fpe=0x1fef360) at fontfile.c:139
#10 0x000000351360f89e in CatalogueUnrefFPEs (fpe=<optimized out>) at
catalogue.c:116
#11 0x000000351360fe41 in CatalogueFreeFPE (fpe=0x1fb8f00) at catalogue.c:272
#12 0x000000000042f09d in FreeFPE (fpe=0x1fb8f00) at dixfonts.c:218
#13 FreeFPE (fpe=0x1fb8f00) at dixfonts.c:214
#14 0x000000000042f107 in FreeFontPath (list=0x1fb54b0, n=2, force=1) at
dixfonts.c:1628
#15 0x0000000000432257 in FreeFonts () at dixfonts.c:1998
#16 0x0000000000422f1e in main (argc=<optimized out>, argv=0x7fff89fd3fb8,
envp=<optimized out>)
    at main.c:329

Downgrading back to xorg-x11-drv-intel-2.14.0-6.fc15.x86_64 makes the
problem go away.

Version-Release number of selected component (if applicable):
xorg-x11-drv-intel-2.15.0-3.fc15.x86_64

How reproducible:
100%

[reply] [-]
Private
Comment 1 Ian Pilcher 2011-05-17 20:37:54 EDT

Created attachment 499495 [details]
Full backtrace of X server deadlock

[reply] [-]
Private
Comment 2 Ian Pilcher 2011-05-18 14:46:22 EDT

It looks like the problematic commit is one of:

e1ff5182304e00c0d392092069422cae7626cf8d  Handle drawable/client
    destruction in pending swaps/flips

86f23f21ab57fcbc031bcd2b8f432a08ff4cc320  Skip client and drawable
   resource delete calls when deleting frame event

I wasn't able to test with only the first commit, because KDE gets stuck
on its "splash screen".

Comment 1 Ian Pilcher 2011-05-20 14:08:56 UTC

Adding Keith Packard to cc list, since his commits cause/expose/trigger the
problem.

Comment 2 Ian Pilcher 2011-05-20 14:41:59 UTC

One other data point.  I'm using the following script to reproduce the
problem:

#!/bin/bash

export DISPLAY=:0

firefox http://www.cnn.com &>/dev/null &
kwrite &>/dev/null &
glxgears &>/dev/null &
sleep 15
qdbus org.kde.screensaver /ScreenSaver org.freedesktop.ScreenSaver.SetActive true
sleep 30
qdbus org.kde.screensaver /ScreenSaver org.freedesktop.ScreenSaver.SetActive false
sleep 15
killall kwrite
sleep 2
killall firefox
sleep 2
killall glxgears
sleep 2
qdbus org.kde.ksmserver /KSMServer logout 0 0 0

The interesting thing is that the problem does not occur without the
"killall ..." commands.  There's something about closing the windows (or
the way that KWin does it) that triggers the issue.

Comment 3 Ian Pilcher 2011-05-20 17:39:24 UTC

I am unable to reproduce this problem when booting with maxcpus=1 or
setting MALLOC_CHECK_ to any value.

Comment 4 Ian Pilcher 2011-06-06 21:45:26 UTC

I haven't seen this for a couple of weeks now.  Given the "raciness" of
the symptoms, it's hard to say whether the problem is really fixed or
still lurking (or even where the problem is/was).

Closing for now.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.