playing videos + changing desktop scaling, triggering XError: BadWindow

[totaam]

Issue migrated from trac ticket # 1200

component: server | priority: minor | resolution: wontfix | keywords: x11

2016-05-18 01:28:43: afarr created the issue

---

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

[totaam]

2016-05-20 05:31:26: antoine changed status from new to assigned

[totaam]

2016-05-20 05:31:26: antoine commented

---

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.

[totaam]

2016-05-20 19:55:13: afarr commented

---

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.

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2016-08-10 06:15:59: antoine changed status from assigned to closed

[totaam]

2016-08-10 06:15:59: antoine set resolution to wontfix

[totaam]

2016-08-10 06:15:59: antoine changed title from 0.18.0 server with limited resources, playing videos & neurotically adjusting av-sync-delta eventially triggering XError: BadWindow to playing videos + changing desktop scaling, triggering XError: BadWindow

[totaam]

2016-08-10 06:15:59: antoine commented

---

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