[winswitch] "Simultanuous" start/upgrade

[Antoine Martin]

On 30/11/14 10:40, Lukas Haase wrote:
> 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'
This look like a real xpra bug. If you file a ticket, we should be able
to fix it.
Try triggering the error with:
XPRA_SYNCHRONIZE=1 xpra ...
and / or:
xpra -d error ...
It will print a lot of debug, which should include more details about
the caller.

We do have a call to trap.swallow_synced, so it should have flushed the
error on the spot instead of allowing it to go through to gdk where it
causes the crash.
> 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)
That's just the standard gdk x11 error message when it receives an error
it does not expect.
> 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).
Plain-X and VNC are not window managers... so they just do not have any
code to run at all. Apples and oranges really.
> But I understand that xpra developers can't do anything about proprietary software.
Generally not, but this looks like a pure xpra bug.
> 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.
That's interesting, the mdns code interacts with dbus and the main loop.
Since it is reproducible, I am fairly confident we can fix this
reasonably quickly.
> 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)
That's a gdk message we can't get rid of, it assumes command line
arguments that don't exist..

Antoine

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