Xpra: Ticket #1200: playing videos + changing desktop scaling, triggering XError: BadWindow

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.



Fri, 20 May 2016 04:31:25 GMT - Antoine Martin: status changed; keywords set

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.


Fri, 20 May 2016 18:55:12 GMT - alas:

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.


Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed


Wed, 10 Aug 2016 05:15:58 GMT - Antoine Martin: status, summary changed; resolution set

Unless this causes real problems, let's not worry about this one.


Sat, 23 Jan 2021 05:17:43 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1200