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

Josh Triplett josh at joshtriplett.org
Sun Jul 26 14:41:19 PDT 2009

On Fri, Jul 24, 2009 at 07:11:59PM -0700, Jamey Sharp wrote:
> 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.
> 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.

Yeah, it does seem like we can't do anything better here.  Oh well.

- Josh Triplett

More information about the Xcb mailing list