Opened 5 years ago
Closed 4 years ago
#1091 closed defect (wontfix)
Scaling and passing session back and forth between clients triggering a 'g_object_unref' warning
Reported by: | alas | Owned by: | alas |
---|---|---|---|
Priority: | trivial | Milestone: | 0.17 |
Component: | client | Version: | trunk |
Keywords: | Cc: |
Description
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).
Change History (5)
comment:1 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|
comment:2 Changed 5 years ago by
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.
comment:3 Changed 5 years ago by
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()
comment:4 Changed 5 years ago by
Priority: | major → trivial |
---|
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.
comment:5 Changed 4 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Not going to worry about this one, exit from the tray or menu instead of using control-C and things should be fine.
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.