Bug 1397

Summary: kbounces crashes composite extension
Product: xorg Reporter: Clemens Fruhwirth <clemens>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: high CC: erik.andren
Version: 6.8.0   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Clemens Fruhwirth 2004-09-15 23:18:19 UTC
Running KBounce and losing a game will hardlock the X server. This is
reproducible with the Composite extension enabled. This even happens if there is
no xcompmgr running. Can anyone confirm it's reproducibility?

Qt: 3.3.0
KDE: 3.3.0
KBounce: 0.5
Comment 1 Clemens Fruhwirth 2005-02-02 04:41:57 UTC
this bug is still present in 6.8.2RC3.

stracing the X process shows, that it get's stuck in a SIGALRM, sigreturn,
futex_wait loop and does not handle any socket traffic.

if anyone has KDE installed, just run kbounce and lose a game. the crash happens
right before the "you lost" dialog.
Comment 2 Clemens Fruhwirth 2005-02-19 07:39:51 UTC
I'm tapping in the dark, with respect to this bug. stracing Xorg in -dumbSched
shows, that X gets stuck waiting for a futex. Inspecting the address of the
futex reveals that it comes from glibc, and is the malloc futex.

Updating glibc doesn't help. Normally I'd suspect it to be a bug in glibc, that
glibc has some kind of race that causes it to loss synchronization. But this bug
is only reproducable with Composite enabled, so I'm wondering if there is
something in Xorg which can deadlock? Another synchronization mechanism? 

I compiled Xorg with debug, but I'm not sure what's the gain, except it's
awefully slow. A practical question, is there a way to produce a stack trace
when the program is in kernel mode? I really don't think so, however..

Or is there some kind of function call log, so I can see what functions are
called before X locking?

Comment 3 Clemens Fruhwirth 2005-07-09 21:20:39 UTC
With the nvidia binary driver 1.0.6* series, and a screen depth of 24bit
(instead of 16bit) it seems to  work.. any idea why 24bit should work better
than 16bits?

another strange thing I observed is, that the kbounce window does not drop any
shadow, when using xcompmgr to generate shadows. So, is this some kind of
special window that circumvents composite rendering for some reason? .. just
guessing.
Comment 4 Eric Anholt 2005-09-30 17:40:44 UTC
Is this using the nvidia driver?  Please retest with an open-source driver,
because the symptoms you describe are those of a driver bug.
Comment 5 Erik Andren 2006-04-02 22:55:03 UTC
I'm closing this bug due to the lack of inactivity. If you are able to reproduce
this bug with a current version of xorg, please reopen. 

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.