Couldn't kill "xpra attach" after emacs locked up

[totaam]

Issue migrated from trac ticket # 9

component: client | priority: major | resolution: worksforme

2011-08-18 02:27:40: FredSRichardson created the issue

---

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

[totaam]

2011-08-18 13:10:42: antoine changed status from new to accepted

[totaam]

2011-08-18 13:10:42: antoine commented

---

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?)

[totaam]

2011-08-18 16:55:32: FredSRichardson commented

---

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).

[totaam]

2011-08-18 17:20:51: lindi commented

---

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.

[totaam]

2011-08-18 17:26:03: antoine commented

---

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

[totaam]

2011-08-18 17:33:01: FredSRichardson commented

---

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.

[totaam]

2011-08-18 17:44:49: antoine commented

---

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.

[totaam]

2011-08-18 18:13:59: FredSRichardson commented

---

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

[totaam]

2011-08-22 17:11:03: FredSRichardson commented

---

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).

[totaam]

2011-08-22 17:12:39: FredSRichardson uploaded file server-14.2011_08_22.log (87.4 KiB)

[totaam]

2011-08-22 17:12:54: FredSRichardson uploaded file client-2011_08_22-end.log (92.3 KiB)

[totaam]

2011-08-22 18:36:47: antoine commented

---

Thx.

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

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

[totaam]

2011-08-30 13:47:09: FredSRichardson commented

---

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.

[totaam]

2011-08-30 13:56:22: antoine commented

---

IIRC there was nothing obvious in the logs

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

[totaam]

2011-08-30 15:11:52: FredSRichardson commented

---

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

[totaam]

2011-09-23 15:46:14: antoine commented

---

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?

[totaam]

2011-11-21 14:25:26: totaam changed status from accepted to closed

[totaam]

2011-11-21 14:25:26: totaam changed resolution from ** to worksforme

[totaam]

2011-11-21 14:25:26: totaam commented

---

No updates, closing.

[totaam]

2012-02-20 19:46:24: totaam