Passing a session back and forth between osx client 0.17.0 r11687 and same build window client, with 0.17.0 r11692 fedora 23 server, I'm stumbling across the tracebacks mentioned in #976 (potentially related to #980 as well):
2016-01-13 13:47:45,465 server is not responding, drawing spinners over the windows 2016-01-13 13:48:38,654 Connection lost /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11687/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:435: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed self.glconfig = None 2016-01-13 13:48:38,693 sound output stopping /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11687/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:434: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed self._backing = None /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11687/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:998: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.Window.destroy(self) /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11687/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:365: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.main()
In this case, it coincided with a disconnection (due to another client connecting) while the latency was so bad that I was getting spinners long enough to also trigger a timeout (I suspect).
Server side I also got a 2016-01-13 13:47:43,773 unknown or invalid packet type: damage-sequence from Protocol(tcp socket: ...) message, referring to the OSX client's IP (and later another referring to the windows client's IP when the latency caused it spinners and a disconnection - though the windows client had no error messages other than the expected server ping timeout message).
That's a strange one, similar to what r11653 is meant to avoid.
I guess it could also happen if we were calling the cleanup code from the wrong thread, but the "Connection lost" handler runs in the UI thread.
Is this only occurring with OSX?
The unknown or invalid packet type error is a race condition which happens when we are processing packets from a client as it is being disconnected, r11702 should make this harder to hit. Doing this properly would be hard and is probably not worth the effort.
Seems to only be happening on osx.
While I have gotten the above when passing a session back and forth between clients, I've also occasionally seen the last one, specifically, even when just using control-c to close session:
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11715/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:365: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.main()
Will watch extra carefully with windows and whatever linux I might play with in semi-near future.
Using control-c server side while osx client is connected, the message is slightly different:
/Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11761/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:998: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.Window.destroy(self) /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11761/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:365: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.main()
Maybe r12151 will help - can't hurt?
I believe that these warnings fire because we are accessing UI objects as we shutdown. You should be able to reproduce without needing another client, just by running xpra disconnect on the server - it should have the same effect: sending a disconnect packet to the client.
I am lowering the priority because I don't think this is likely to cause problems.
Not going to worry about this one, exit from the tray or menu instead of using control-C and things should be fine.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1091