xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Custom Query (2683 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (55 - 57 of 2683)

Ticket Resolution Summary Owner Reporter
#9 worksforme Couldn't kill "xpra attach" after emacs locked up Antoine Martin FredSRichardson
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

#14 worksforme xpra died Antoine Martin FredSRichardson
Description

I was working away in emacs over X when xpra died. The console messages looked like this:

_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
Connection lost
Error reading from connection: I/O operation on closed file

trying to reconnect gave me this message:

'setxkbmap -query' failed with exit code 255

the server will try to guess your keyboard mapping, which works reasonably well in most cases
however, upgrading 'setxkbmap' to a version that supports the '-query' parameter is preferred
Connection failed: [Errno 111] Connection refused
Connection lost
Error reading from connection: I/O operation on closed file

the tail end of the xpra log for this display looked like this:

['xkbcomp', '-', ':14'] successfully applied
['xmodmap', '-'] successfully applied
The program 'xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 4260582 error_code 3 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

so I suspect the real problem is the X error, but I don't understand what happened.

#204 needinfo GHS Multi Freezes when using it with Xpra Antoine Martin Gdwarner
Description

This occurs when using a proprietary piece of software called Greenhils MULTI. It seems to be a gtk2 app(?). Certain actions cause dialogs to pop up and more often than not, these cause the program to freeze. It does not freeze, however, when being used with VNC or regular X11 forwarding.

I've also tried it with Xdummy, and the results are the same.

I will attach the log with "-d all" enabled. If I had to guess, I would say the problem corresponds to this part of the log which constantly repeats once the freeze occurs:

2012-11-02 20:46:15,585 x_event_filter event=('wimpiggy-cursor-event', None)/100
2012-11-02 20:46:15,586 Cursor event received
2012-11-02 20:46:15,586   event was delivered to window itself
2012-11-02 20:46:15,586   forwarding event to a XpraServer handler's wimpiggy-cursor-event signal
2012-11-02 20:46:15,587   forwarded
2012-11-02 20:46:15,587   not forwarding to Wm handler, it has no wimpiggy-cursor-event signal

I regret that this is only happening with proprietary software, and therefore, realize it may be difficult to debug with the log alone since the maintainers won't be able to reproduce first-hand.

Note: See TracQuery for help on using queries.