f11 X "hang"

[Adam Jackson]

On Sun, 2009-05-31 at 21:38 -0700, David L wrote:
> I'm having a strange problem where X is kinda sorta
> hanging... I can move the mouse and the keyboard
> is responsive to changes in caps lock, but I can't
> switch workspaces or select a new window or do
> anything useful from my X session.  The way I'm
> getting into this state is to do this:
> 
> strace ekiga
> 
> When I do this, I see a bunch of strace output
> but the ekiga window never pops up and I can't
> do anything until I ssh into the system and kill
> ekiga.  The last thing I see in the strace is this:

strace'ing X apps is a great way to livelock yourself.  You really don't
want to do this.

The livelock works like this.  Say you're running strace under
gnome-terminal.  strace pumps out a _lot_ of output, so g-t will be
sending bajillions of requests to the X server.  strace dutifully prints
the trace of sending all those requests to the server, and g-t sends
them on as yet more X requests.  Eventually, X's internal client
scheduler says "too much stuff from you, g-t, lets let other clients
have a chance", and puts the g-t connection to sleep.  (Not SIGSTOP,
just ignores that socket for a while.)

While the g-t connection is scheduled out, ekiga takes a server grab for
some reason.  Server grabs are this kind of nasty thing in X where one
client can monopolize the attention of the X server.  They suck, but
they're the only way to work around some of the inherent races in the
protocol, so we're kind of stuck with them.  Anyway, ekiga is still
doing stuff, strace is trying to print it, and g-t is trying to send the
printout to the X server, which is dutifully only paying attention to
ekiga.

So now, the send queue for g-t's X socket fills up.  Shortly thereafter,
strace's write()s to stdout block, because g-t is stuck trying to send
to the X server and isn't attending to strace's stdout.  Uh oh, now
strace is sleeping.  But strace has ekiga under ptrace control, which
means ekiga is stopped.  Livelock: ekiga can't advance until strace
advances; strace can't advance until g-t advances; g-t won't advance
until ekiga releases the X server grab; ekiga won't ever release the
server grab because it's stuck in ptrace wait.

IWBNI screen(1) had a mode where it would track the visible area
updates, and if they're not being processed, coalesce them internally
until its output queue is drained and then send them all as one big
screen refresh.  If it did, then you could run strace under screen and
avoid this livelock; g-t might get swamped for a while, but strace
wouldn't, so ekiga would always be able to advance.  But it doesn't, at
least not that I've been able to find.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090601/937286ea/attachment.sig>