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.

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?

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.

Is this using the nvidia driver?  Please retest with an open-source driver,
because the symptoms you describe are those of a driver bug.

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.