Bug 44198

Summary: ../../src/xcb_conn.c:155: int write_vec(xcb_connection_t *, struct iovec **, int *): Assertion `!c->out.queue_len' failed.
Product: XCB Reporter: Morten Hustveit <morten.hustveit>
Component: LibraryAssignee: xcb mailing list dummy <xcb>
Status: RESOLVED FIXED QA Contact: xcb mailing list dummy <xcb>
Severity: normal    
Priority: medium CC: net147
Version: 1.10   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Morten Hustveit 2011-12-27 13:51:31 UTC 
This simple test case from 2008 aborts on an assertion within 1 second on every run:

  http://lists.freedesktop.org/archives/xcb/2008-November/004030.html

The test case will trigger any of two asserts, but one of them can be eliminated by applying the patch found here:

  https://bugs.freedesktop.org/show_bug.cgi?id=29875

The assertion mentioned in this report's summary remains.
Comment 1 Uli Schlachter 2011-12-28 04:37:03 UTC 
This assertion seems to be a bug in Xlib instead of xcb. I added the following assert() to xcb_writev() (since xcb_take_socket() has to be called before it may be used) and now this assert triggers instead of the one from the summary.

 assert(c->out.return_socket != NULL); 

Should I send this assert() as a git-formatted patch to the mailing list?
Should this bug be reassigned to Xlib?
Comment 2 Josh Triplett 2011-12-29 17:42:44 UTC 
(In reply to comment #1)
> This assertion seems to be a bug in Xlib instead of xcb. I added the following
> assert() to xcb_writev() (since xcb_take_socket() has to be called before it
> may be used) and now this assert triggers instead of the one from the summary.
> 
>  assert(c->out.return_socket != NULL); 
> 
> Should I send this assert() as a git-formatted patch to the mailing list?
> Should this bug be reassigned to Xlib?

By all means reassign this bug to Xlib.  However, please don't add assertions to XCB that trigger on programs using Xlib; we've learned from previous assertions that people really don't like having their programs throw assertion failures, and when the assertions come from XCB they blame XCB rather than blaming Xlib or their programs.  Let's have them correctly blame Xlib instead this time. :)

That said, thanks for your further diagnosis of the problem.  From what you found, it definitely sounds like Xlib tried to call xcb_writev without owning the socket, which should never happen.
Comment 3 Uli Schlachter 2012-01-24 12:06:23 UTC 
ARGH.
Took me a while but I finally figured it out. The fix is simple:

Just call XInitThreads() before XOpenDisplay() and all the problems disappear.

(Reassigning to libX11 and closing as INVALID)
Comment 4 Ulf Hermann 2014-04-08 13:19:02 UTC 
I don't think just calling XInitThreads() fully resolves it as I still get bugs like https://bugreports.qt-project.org/browse/QTCREATORBUG-11960 and https://bugreports.qt-project.org/browse/QTBUG-31935 even though Qt calls XInitThreads().

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.