[Xcb] Opening/closing (and resizing) many windows

[Jamey Sharp]

Hello Edwin!

On Tue, Aug 02, 2011 at 05:19:27PM +0100, Edder wrote:
> Hi all,
> 
> I am building a plot library based on cairo and xcb.
> (Available at https://gitorious.org/realtimeplot) (branch xcb).
> 
> Mostly this seems fine, but for some reason sometimes when I open a
> couple of plots at almost the same time some of them don't show up (no
> window is opened). This is always solved by sleeping between opening
> those windows. I have tracked down this issue and found that the
> problem is caused by my xcb code. The problem seems to happen more
> commonly within xmonad (a tiling window manager) and therefore might
> have something to do with the fact that xmonad resizes/moves the
> window as soon as it is opened. Anyway some code that causes it to
> happen a lot for me can be found here:
> https://gitorious.org/realtimeplot/realtimeplot/blobs/xcb/examples/xcb_base.cc
> (compile with gcc examples/xcb_base.cc -lxcb -lpthread)
> This code should result in 4 open windows, but often only opens 1,2 or 3.
> 
> Am I doing something wrong with my xcb initialization?
> 
> Cheers,
> 
> Edwin
> 
> P.S. I had exactly the same problem with xlib, which is why I decided
> to port to xcb

Josh and I think that you're racing with the window manager,
particularly by rapidly closing connections and opening new ones. Here
are two bugs that I think are relevant:

https://bugzilla.gnome.org/show_bug.cgi?id=581526
https://bugs.freedesktop.org/show_bug.cgi?id=21583

I've attached our re-written version of your test program, which dumps
the window IDs allocated to each window you create, and the events sent
in response on the connections you don't immediately close.  We managed
to reproduce the race a few times, and when we did, we ended up with 3
normal windows and one window with no window-manager decorations on it.
When that happened, we also noticed the XID of that undecorated window
corresponded to an XID reused first for one or more of the windows from
the closed connections, then for one of the windows of a connection that
stayed open.  (The moment you close a connection, its XIDs become
available for reuse.)  The event dump for that connection showed a pile
of events on that window, including several sets of reparent/map/unmap,
whereas you'd only expect one such set for a normal window handled by
the window manager.  So, we think the chain of events looks something
like this:

- Client opens connection 1
- Client gets XID a
- Client creates and maps a window with XID a
- Client closes connection 1
- Client opens connection 2
- Client gets XID a again (since connection 1 doesn't own it anymore)
- Client creates and maps a window with XID a
- Window manager gets around to handling the various windows
- Client's connection 2 ends up getting various events from the window
  manager's actions on window a of connection 1
- Window manager now doesn't have a sensible state for window a; it ends
  up in the "Withdrawn" state

This doesn't represent a bug in xlib or xcb.  I don't know whether the
window manager can do anything sensible about this race either, though
it would probably help if the window manager handled events strictly in
order, which it probably doesn't.  That would still let connection 2 get
events meant for connection 1, but at least the window might end up in a
sensible state.  The server could reduce the likelihood of a race by not
reusing client IDs quite as eagerly, and round-robining them instead,
though that still only masks the bug.

Finally, and most importantly, you can almost certainly avoid the
problem by not rapidly closing and opening connections like your test
program does. :)  You should maintain a single connection and use that
for any X operations you want to do.

Jamey Sharp and Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: examples_xcb_base.c
Type: text/x-csrc
Size: 2050 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20110802/f2b6f2fc/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20110802/f2b6f2fc/attachment.pgp>