https://bugzilla.novell.com/show_bug.cgi?id=473302
User matz@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=473302#c6
--- Comment #6 from Michael Matz 2009-02-06 09:53:27 MST ---
I can reproduce it now. From a remote machine I simply do
xset dpms force standby
KDE3 will notice this, and starts kdesktop_lock and the kss module (the program
that paints something nice), immediately SIGSTOPs that kss module (because
due to DPMS it wouldn't be visible anyway), and then the countdown to the bug
starts.
stracing X then reveals that the select() loop starts with a 870 something
seconds timeout, which is reduced with each call to select, by the amount it
took for the select to return plus 20 milli-seconds. So, for the first
~870 seconds after the screensaver becomes active all is well, as there's
still a time-out so select only returns seldomly.
After these ~870 seconds the timeout value is 0, and _doesn't_ get reset to
something larger again. From then on X will take 100% CPU. I can reproduce
this reliably, but it takes some time to show up (exactly the ~870 seconds).
I've tried looking at the patches that went in after beta4. The only thing
which barely is related to screen-saving seems to be dpms_screensaver.diff,
from 2008-11-28. I think this was shortly after beta4 was released. The patch
itself looks innocent (just introduces a call to dixSaveScreens()), but
perhaps it triggers a bug somewhere else (in the timeout calculations for
select).
[probably irrelevant:
grepping for "select" in all diffs of xorg-x11-server reveals some occurences
in xorg-server-xf4vnc.patch and xorg-server-xf4vnc-busyloop.diff, where
at least some in xf4vnc.patch also explicitely use a {0,0} timeout. That
at least looks dubious, as that usually is not what one wants. But as this
is vnc, it's most probably unrelated.]
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.