[Xcb] [BUG] iceweasel (debian's firefox) hungs on shutdown in libxcb1

[Jamey Sharp]

On Fri, Jul 24, 2009 at 5:31 PM, Josh Triplett<josh at freedesktop.org> wrote:
> On Mon, Jul 20, 2009 at 01:10:01PM -0700, Barton C Massey wrote:
>> Note that, to the extent that calling into a closed
>> interface probably should never hang or crash, it seems to
>> me to be to some extent our bug too.  However, it will be
>> much easier for us to work on if the Qt bug (?) is fixed
>> first.
>
> Yeah, we probably want to do the cairo thing here, and have XCB calls on
> a closed interface fail gracefully.

There are two cases. If either xcb_disconnect or XCloseDisplay has
been called, then all bets are off. xcb_disconnect frees the
xcb_connection structure, and XCloseDisplay frees the Display
structure whether it's built with XCB support or not, and I think
that's the right thing for those functions to do. In this case,
applications just need to be careful that the lifetime of their
references to the Display is not longer than the lifetime of the
Display itself: nothing X-specific there.

On the other hand, if the connection closed due to an I/O error (such
as "connection closed"), then the story is a little bit different.
Since nobody calls disconnect or close in that case, xcb_writev's
"if(c->has_error)" should already cause the "cairo thing" to happen.

I think this application has explicitly called XCloseDisplay before
exiting, because libXrender's cache of QueryExtension results has had
this Display removed from it (as evidenced by XRenderFindDisplay
calling XInitExtension), and because xcb_writev's has_error test isn't
firing. I don't know why calling poll(2) with c->fd, which should
already have been passed to close(2), doesn't just immediately return
an error; but hey, it's freed memory. It's probably been overwritten
with something that looks like a different open file descriptor.

Jamey