xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1200 closed defect (wontfix)

playing videos + changing desktop scaling, triggering XError: BadWindow

Reported by: alas Owned by: Antoine Martin
Priority: minor Milestone: 1.0
Component: server Version: trunk
Keywords: x11 Cc:

Description

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.

Change History (4)

comment:1 Changed 3 years ago by Antoine Martin

Keywords: x11 added
Status: newassigned

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.

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

comment:4 Changed 3 years ago by Antoine Martin

Resolution: wontfix
Status: assignedclosed
Summary: 0.18.0 server with limited resources, playing videos & neurotically adjusting av-sync-delta eventially triggering XError: BadWindowplaying videos + changing desktop scaling, triggering XError: BadWindow

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

Note: See TracTickets for help on using tickets.