xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#9 closed defect (worksforme)

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

Reported by: FredSRichardson Owned by: Antoine Martin
Priority: major Milestone: 0.0.7.x
Component: client Version: 0.0.7.26
Keywords: Cc:

Description

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

Attachments (2)

server-14.2011_08_22.log (87.4 KB) - added by FredSRichardson 8 years ago.
client-2011_08_22-end.log (92.3 KB) - added by FredSRichardson 8 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 8 years ago by Antoine Martin

Status: newaccepted

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

comment:2 Changed 8 years ago by 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).

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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.

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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

comment:8 Changed 8 years ago by 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).

Changed 8 years ago by FredSRichardson

Attachment: server-14.2011_08_22.log added

Changed 8 years ago by FredSRichardson

Attachment: client-2011_08_22-end.log added

comment:9 Changed 8 years ago by Antoine Martin

Thx.

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

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

comment:10 Changed 8 years ago by 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.

comment:11 Changed 8 years ago by Antoine Martin

IIRC there was nothing obvious in the logs

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

comment:12 Changed 8 years ago by FredSRichardson

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

comment:13 Changed 8 years ago by 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?

comment:14 Changed 8 years ago by Antoine Martin

Resolution: worksforme
Status: acceptedclosed

No updates, closing.

comment:15 Changed 8 years ago by Antoine Martin

Milestone: 0.0.7.x
Version: 0.0.7.26
Note: See TracTickets for help on using tickets.