Yet more from testing a fedora 23 server allocated only 512MB of memory to try to repro #1111 memory issue.
Still 0.18.0 r12578 windows client, 0.18.0 r12577 fedora 23 server.
After hours of running and regularly (or for stretches senselessly) adjusting the av-sync-delta
with the control channel... I eventually saw this traceback (amidst a number of instances of #1198 & #1199 when scaling was < 100%):
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/x11/server.py", line 914, in _process_configure_window self._desktop_manager.configure_window(window, ax, ay, aw, ah, resize_counter) File "/usr/lib64/python2.7/site-packages/xpra/x11/server.py", line 125, in configure_window win.map() File "/usr/lib64/python2.7/site-packages/xpra/x11/gtk2/models/window.py", line 310, in map log("client window %#x mapped", self.xid) File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/error.py", line 168, in __exit__ trap._exit(True) File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/error.py", line 100, in _exit raise XError(get_X_error(error)) xpra.gtk_common.error.XError: XError: BadWindow
... I think I triggered it when I adjusted desktop-scaling
back to 67% to confirm cause of #1199, after having adjusted it back to 100% for a number of hours in order to test something a little bit more sane to try to repro #1111.
Didn't get it when trying to repro though... so not entirely certain what awful abuse of this poor server without enough resources to defend itself might've actually been responsible.
It looks like the window is gone when we try to reinitialize it.
We are working asynchronously with the X11 server and client applications, so it is possible for windows to disappear from underneath us. Usually, this is caught by the gdk layer and we then get a nice signal which we handle without warnings, taking care of cleaning all references to the closed window. But in this case, the window "map" code goes straight to X11, bypassing gdk.
I've tried adding a window lookup in the small synchronized block, but gdk caches the window object so this doesn't tell us anything. Testing with an xterm by hand, calling any functions on the window object after it is closed will cause a complete hard crash.
As it is, I don't think the server will crash when this happens, so we'll probably just have to live with the ugly stacktrace.
Well, I had to induce a lot of tracebacks/errors for a good long while before I induced that one, and it didn't seem to crash the server, so it can probably be lived with.
Milestone renamed
Unless this causes real problems, let's not worry about this one.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1200