[Xquartz-dev] Time Machine Backup Alert

[Gene Selkov]

Jeremy,

Please pardon my ignorance, but if it is waiting patiently, why is the
CPU time counted and the fan is blowing at full speed? I would
understand if it were wating in its own loop, but this is a unix.
Maybe we have found a bug in darwin?

>  have you seen this with other apps?

No, I haven't seen this with other apps, but I don't run too many.
Other than firefox and emacs-app, I hardly use anything on this mac;
occasionally I run Apple utilities, such as (now very useful) Activity
Monitor. I mostly use this machine as a terminal and a drawing pad. I
use it as a computer, too, but my computation does not involve GUI, so
I cannot tell. Negative, based on whatever little I have seen.

> Does it happen only when using your stylus?

No, it happens without the stylus attached. Gimp skips mouse events
just as well.

On the account of the lost events, I have just tried the stylus with
Ink, and it works smoothly, even if I write extremely quickly. So I
don't think the events are lost in the kernel space.

I've made a couple more experiments since my last message.

First, I tried to attach gdb to it, in the hope that I could stop it
inside one of those crazy idle loops and get a meaningful backtrace.
Guess what. It didn't do that with gdb attached. Almost as soon as I
detached gdb, the same X11.bin went crazy again. While in gdb, I could
work normally  without any perceptible impediment, except gimp was
missing the pointer events (from the stylus, as well as the mouse).

Then I randomly fooled around with it, hoping to find a trigger for
this behavior. 4 times in a row, it started at the same moment the
screen timed out and turned off. I could hear the fan kick into high
speed seconds later, and found that X11.bin was at 100% by logging in
from another machine (without touching the keys). I had almost
finished typing the announcement of this finding, when I noticed that
the 5th screen time-out experiment turned out negative, and so did the
6th and the 7th. So seemed to be the 8th, but then I left for 30
minutes without touching it, and when I came back, X11.bin was again
spinning the fan. So I am still not sure whether there is a reliable
way to reproduce it, but statistically, this has been a likely
sequence:

  1. Start X11
  2. Start gimp and do something in it.
  3. Switch to another app for a while. Even transferring focus to
Activity Monitor may be enough. Sometims it takes only 10-15 seconds
to activate the fan; sometimes multiple minutes, and almost as often
as not, nothing will happen during a very long time.

  4. But if it does happen, any activity in gimp or any other X11
client brings it back to normal. Until it loses focus or until the
screen turns off, in which case the high idle is likely to occur
again.

Returning to normal seems to be new in 2.3.2.1. In rc3 and rc4, I had
to restart the machine (another fact suggestive of a kernel-space
problem).

By the way, when it does this, ps shows it as running (as does
Activity Monitor):

35884   ??  R     20:49.98
/Applications/Utilities/X11.app/Contents/MacOS/X11.bin -psn_0_3273503
35897   ??  S      0:00.05 /usr/X11/bin/xterm
35898   ??  S      0:00.02 /bin/sh /usr/X11/bin/startx
35964   ??  S      0:00.01 /usr/X11/bin/xinit
/usr/X11/lib/X11/xinit/xinitrc -- /usr/X11/bin/X :0 -nolisten tcp
-auth /Users/selkovjr/.serverauth.35898
35968   ??  S      0:00.00 /usr/X11/bin/X :0 -nolisten tcp -auth
/Users/selkovjr/.serverauth.35898

Attaching gdb as an anchor to lull it could be a fine hack, but it
doesn't solve the event-skipping problem in gimp, which makes it
useless as a drawing tool. That may very well be a bug in gimp, and I
was going to set off in that direction, but Tom's observation of
missing keystrokes made me think again. Is it possible that something
is broken where all events are handled? Also, the same version of gimp
and the same tablet work fine with the recent Xorg in linux. How much
code does that isolate as suspect?

Thanks,

--Gene