xpra icon
Bug tracker and wiki

Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#14 closed defect (worksforme)

xpra died

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

Change History (4)

comment:1 Changed 9 years ago by Antoine Martin

What release was this? Looks older than svn r146 from the log output, not that I expect trunk to fix this particular issue unfortunately.

AFAIK, the only way to know exactly where the error came from is to run xpra in gdb with GTK set to "sync" mode. I will add documentation on how to do this to the website.

When this happens, is the xpra server process still running? Is the Xvfb process still there?
If the xpra server has crashed but Xvfb is still there, you should be able to re-attach to it with the "xpra --use-display" switch.

comment:2 Changed 9 years ago by FredSRichardson

This is actually a recent (i.e. a few days ago) SVN checkout of xpra. Running "svnversion" tells me I'm at version r150. I don't think I have conflicts with competing packages on my systems (I removed them all before).

When I did "xpra list" it said the session was dead. The xvfb job was still running. I didn't know about re-attaching. I'll try that next time.

I'm very interested in xpra, but I'm also under a crunch and need a robust way of re-attaching to my work environment. I've decided to revert to using GNU screen for the time being.

Thank you for all your efforts in trying to get xpra to work. When I have some time in the future I'll see what I can do to try and help out. Maybe we just need a few more emacs users who know how to debug this stuff...

Last edited 8 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 9 years ago by Antoine Martin

Resolution: worksforme
Status: newclosed

Closing, feel free to reopen if necessary.

comment:4 Changed 8 years ago by Antoine Martin

Milestone: 0.0.7.x
Version: 0.0.7.26

btw, the switch to use to re-attach to a running xvfb is --use-display

Note: See TracTickets for help on using tickets.