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
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?)
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).
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.
I have moved the 'alt gets stuck' to #13 - I'll try to take a look at this asap, please add details there.
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.
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.
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
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).
Thx.
Hmm, sounds like a heisenbug of the timing/race type..
I'll take a look asap (probably end of the week).
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.
IIRC there was nothing obvious in the logs
The best thing would be to get a reproducible test case.
Hmm... sadly this happen several times a day but I can't for the life of me figure out what triggers it.
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?
No updates, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/9