[winswitch] "Simultanuous" start/upgrade

[Lukas Haase]

Hi Antoine,

> On 29/11/14 22:20, Lukas Haase wrote:
> > Hi,
> >
> > Unfortunately xpra is not so stable for me :-( - in two ways:
> > 1.) Sometimes something on the client goes wrong and manually doing "xpra upgrade" helps
> > 2.) Often xpra on the server crashes but leaving the X-server intact s "xpra upgrade" is possible.
> If you report those, then we can fix them.

Unfortunately I have no hope that this would be successful.
I use proprietary, regulated, licensed software.

This is an error which typically occurs:

2014-11-29 22:31:13,349 sent updated screen size to 1 clients: 3120x1050 (max 8192x4096)
/usr/lib64/python2.6/site-packages/xpra/server/picture_encode.py:352: DeprecationWarning: tostring() is deprecated. Please call tobytes() instead.
  data = img.tostring("raw", target_format)
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/gobject_util.py", line 30, in do_get_property
    return getattr(self, getter)(pspec.name)
  File "/usr/lib64/python2.6/site-packages/xpra/x11/gtk_x11/composite.py", line 213, in do_get_property_contents_handle
    trap.swallow_synced(set_pixmap)
  File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 143, in swallow_synced
    self.call_synced(fun, *args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 126, in call_synced
    return self._call(True, fun, args, kwargs)
  File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 118, in _call
    raise e
AttributeError: 'gtk.gdk.Window' object has no attribute 'get_name'

Gdk-ERROR **: The program 'Xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 126938 error_code 9 request_code 14 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.)
aborting...
Abort (core dumped)


I understand that these errors might be caused by "the application should not behave like this" and therefore xpra crashes.
On the other hand, it works over plain X and VNC. Furthermore, neither the application, nor the X server crashes (only xpra) meaning that it's related to xpra (even if it might behave correctly in a strict sense).

But I understand that xpra developers can't do anything about proprietary software.

Interestingly there is a fool-proof way to reproducibly come to an error like this: If xpra is started with "--no-mdns" (which has nothing to do with the application running inside!) and one particular application is started, xpra crashes immideately with the message above (but xpra upgrade is possible afterwards). Without "--no-mdns" it works. This is at least a strong indication that xpra has to do with it.

Other than that, these errors happen sporadically (3-5x/day), often after making a right-click somewhere (apparently where or when it should not be clicked)

Let me know if you think differently and which information I could provide (for example, the suggested --sync option neither works for the application started, nor for xpra)

> > My plan is to create a script that I run within screen and does the following:
> > 1.) Starting xpra with a certain child. If the session already exists, upgrade
> > 2.) Only if the child exits, the script should exit
> > 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop.
> >
> > Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-)
> We don't normally do band aids, but this feature could be useful on its own.
> [...]
> Implementing upgrade-or-start is probably easier than that, and more
> importantly, reliable.

:-) Does it mean I can file a feature request for it?

> [...]
> > Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade?
> > How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not?
> If you really want to script it, you can just use:
> xpra version :1111
> And check the exit code.

But how do I distinguish between "crashed/upgradeable" and "not running at all"?

xpra successfully running:
$ xpra version :1111; echo $?
0.14.12
0

xpra not running at all:
$ xpra version :1111 ; echo $?
xpra initialization error: connection failed: [Errno 2] No such file or directory
1

xpra crashed but not Xserver/aplication (using the "--no-mdns" method described above):
$ xpra version :1111 ; echo $?
xpra initialization error: connection failed: [Errno 111] Connection refused
1

It seems that it would be distinguishable if xpra would return the Errno code.
Or I could grep the stderr output which is not very elegant.



Thank you
Lukas