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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
