Xpra: Ticket #9: Couldn't kill "xpra attach" after emacs locked up

I think some combination of keys causes this problem. Emacs wasn't responding, but the odd thing is that I couldn't kill the process with Ctrl-C!

This is what I got in the console:

^C^CShutting down main-loop
Traceback (most recent call last):
  File "/usr/local/lib/python/xpra/protocol.py", line 67, in cb
    fn(*args, **kwargs)
  File "/usr/local/lib/python/xpra/protocol.py", line 179, in _handle_read
    self._read_decoder.add(buf)
  File "/usr/local/lib/python/xpra/bencode.py", line 35, in add
    self._buf += bytes
KeyboardInterrupt
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])

Here's what I saw at the end of the log:

xkbcomp successfully applied new keymap
Uh-oh, our size doesn't fit window sizing constraints!
Uh-oh, our size doesn't fit window sizing constraints!
Uh-oh, our size doesn't fit window sizing constraints!
Error parsing property WM_TRANSIENT_FOR (type window); this may be a
  misbehaving application, or bug in Wimpiggy
  Data: '\x01\x00\x00\x00'[...?]
Error parsing property WM_TRANSIENT_FOR (type window); this may be a
  misbehaving application, or bug in Wimpiggy
  Data: '\x01\x00\x00\x00'[...?]
Error reading from connection: [Errno 104] Connection reset by peer
Error writing to connection: [Errno 32] Broken pipe
Connection lost
xpra client disconnected.
New connection received
Connection lost


Thu, 18 Aug 2011 12:10:41 GMT - Antoine Martin: status changed

Looks like gtk_main_quit_really() is called whilst the network queues are still active, I think we should trap KeyboardInterrupt and first stop the network thread. However, I am reluctant to make any changes until I can reproduce this issue.

Can you re-produce it easily? (also, I don't think this really matters, but which svn version are you using?)


Thu, 18 Aug 2011 15:55:32 GMT - FredSRichardson:

I'll have to see if I can.

In general there is something very frustrating about using xpra with emacs. The old version was worse in some particular ways (the meta key would lock all the time) which the new version has fixed, but I keep getting "lockups" which I can't seem to replicate.

I think a "monkey at the keyboard" could replicate the lockup problems I have. I'm not sure that it would be easy to replicate the particular problem above.

I am using the latest SVN version (I did a fresh update yesterday before I got this problem).


Thu, 18 Aug 2011 16:20:51 GMT - Timo Juhani Lindfors:

I think I have seen this one. Fred, can you add exact SVN revision numbers to your story? In r130 my alt gets also stuck all the time but let's try to keep one issue per bug report.


Thu, 18 Aug 2011 16:26:02 GMT - Antoine Martin:

I have moved the 'alt gets stuck' to #13 - I'll try to take a look at this asap, please add details there.


Thu, 18 Aug 2011 16:33:01 GMT - FredSRichardson:

I'm at SVN version r134.

I should be clear about this: I no longer get Alt lockups with the newer versions of xpra (new meaning newer than what you get using Ubuntu aptitude).

I now get application level lockups where Emacs does not respond to the keyboard anymore. Sometimes I can minimize and maximize to bring it back or keep clicking the mouse until the Emacs GUI wakes up, but more often I have to Ctr-C my xpra session and re-attach.


Thu, 18 Aug 2011 16:44:48 GMT - Antoine Martin:

Assuming that I am not enough of a monkey to trigger this bug (this would surprise many - nonetheless...), please try running xpra with:

-d all

and/or stracing it when the next lockup occurs so I can get an idea of what it is doing.


Thu, 18 Aug 2011 17:13:59 GMT - FredSRichardson:

Okay, that's an even better idea. I can also try both (-d all and strace) and redirect output to a log file.

Thanks!

-Fred


Mon, 22 Aug 2011 16:11:02 GMT - FredSRichardson:

xpra has been pretty well behaved with the -d all flag. Perhaps it needed the burden of print to stdout ;)

I did finally get a lockup. This is just running with the "-d all" flag. Attached are the server log and the last bit of the client log (which is quite at 48Meg).


Mon, 22 Aug 2011 16:12:39 GMT - FredSRichardson: attachment set


Mon, 22 Aug 2011 16:12:53 GMT - FredSRichardson: attachment set


Mon, 22 Aug 2011 17:36:47 GMT - Antoine Martin:

Thx.

Hmm, sounds like a heisenbug of the timing/race type..

I'll take a look asap (probably end of the week).


Tue, 30 Aug 2011 12:47:08 GMT - FredSRichardson:

Let me know if you need anymore info on this. I've been saving logs, though it's hard for me to figure out where in the log the lockup occurs... I assume it's sometime after the last "key-action" though that seems to be 33K lines back in my log file.


Tue, 30 Aug 2011 12:56:21 GMT - Antoine Martin:

IIRC there was nothing obvious in the logs

The best thing would be to get a reproducible test case.


Tue, 30 Aug 2011 14:11:52 GMT - FredSRichardson:

Hmm... sadly this happen several times a day but I can't for the life of me figure out what triggers it.


Fri, 23 Sep 2011 14:46:13 GMT - Antoine Martin:

There were a number of improvements to the read loop recently (r166 and r156) - does this still occur with the latest version? or even better with trunk?


Mon, 21 Nov 2011 14:25:25 GMT - Antoine Martin: status changed; resolution set

No updates, closing.


Mon, 20 Feb 2012 19:46:24 GMT - Antoine Martin: version, milestone set


Sat, 23 Jan 2021 04:43:06 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/9