qmlscene assert failure: qmlscene: ../../src/xcb_conn.c:180: write_vec: Assertion `!c->out.queue_len' failed.

[Fabio Marconi]

- Spontaneous crash without any apparent reason.
- Except the web browser, no application was in use at the moment of the crash.

Thanks
fabio

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: qmlscene 5.0.1-0ubuntu3
ProcVersionSignature: Ubuntu 3.9.0-1.5-generic 3.9.1
Uname: Linux 3.9.0-1-generic x86_64
ApportVersion: 2.10-0ubuntu3
Architecture: amd64
Date: Mon May 13 20:02:17 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-10-12 (213 days ago)
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20121011)
MarkForUpload: True
SourcePackage: qtdeclarative-opensource-src
UpgradeStatus: Upgraded to saucy on 2013-05-01 (11 days ago)

[Morten-hustveit (morten-hustveit)]

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.

[Psychon-d (psychon-d)]

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?

[Josh Triplett (joshtriplett)]

(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.

[Psychon-d (psychon-d)]

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)

[Pauli (paniemin)]

most likely fix: https://bugs.freedesktop.org/show_bug.cgi?id=44198#c3

To me it appears to be problem threaded access to xcb and xlib. Qt is using xcb but gl library is using xlib to cumminicate with same connection from different threads.

[Pauli (paniemin)]

https://bugreports.qt-project.org/browse/QTBUG-31935

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Timo Jyrinki (timo-jyrinki)]

Marking the bug as Incomplete to indicate it's probably not reproducible anymore. Qt Declarative script engine was rewritten in the Qt 5.2.1 and it's likely the crashes that happened with Qt 5.0.2 do not happen or are different with the new Qt.

[Alberto Salvia Novella (es20490446e)]

If you're still experiencing this bug, please change its status back to 'confirmed'.

[Ulf-hermann (ulf-hermann)]

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().

[Jonathan Liu (net147-t)]

Fixed by http://cgit.freedesktop.org/xcb/libxcb/commit/?id=be0fe56c3bcad5124dcc6c47a2fad01acd16f71a

[Timo Jyrinki (timo-jyrinki)]

I'm not sure if this is still reproducable with Qt 5.3.0, but the upstream seems to point to the libxcb upstream bug which now has a fix. Another Qt bug linked to the upstream Qt bug report was also reported fixed in Qt 5.3.0.

[Michael Abrahams (miabraha)]

Does this bug still occur? If not, might xcb-xinput be ready to release for Ubuntu? The lack of this package is holding back the ability to install the updated KDE5/Frameworks Wacom tablet control panel module.

[Henry (sh37092)]

This data-race occurred in Virtualbox with 3D acceleration enabled.

Below is stack trace of this data race. This bug was fixed by upstream three years ago but it hasn't merged into our code. I have patched my library and Virtualbox haven't crashed since then.

Fix: https://cgit.freedesktop.org/xcb/libxcb/commit/?id=be0fe56c3bcad5124dcc6c47a2fad01acd16f71a

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/virtualbox/VirtualBox --startvm Windows 10'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f7c36b4fcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f7c36b4fcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f7c36b530d8 in __GI_abort () at abort.c:89
#2 0x00007f7c36b48b86 in __assert_fail_base (fmt=0x7f7c36c99830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion@entry=0x7f7c2b55a615 "!c->out.queue_len", file=file@entry=0x7f7c2b55a600 "../../src/xcb_conn.c", line=line@entry=186,
    function=function@entry=0x7f7c2b55a630 <__PRETTY_FUNCTION__.10950> "write_vec") at assert.c:92
#3 0x00007f7c36b48c32 in __GI___assert_fail (assertion=assertion@entry=0x7f7c2b55a615 "!c->out.queue_len", file=file@entry=0x7f7c2b55a600 "../../src/xcb_conn.c",
    line=line@entry=186, function=function@entry=0x7f7c2b55a630 <__PRETTY_FUNCTION__.10950> "write_vec") at assert.c:101
#4 0x00007f7c2b54ee5b in write_vec (count=0x7f7c00cd9ba4, vector=0x7f7c00cd9ba8, c=0x7f7c0835d020) at ../../src/xcb_conn.c:186
#5 _xcb_conn_wait (c=c@entry=0x7f7c0835d020, cond=cond@entry=0x7f7c0835e140, vector=vector@entry=0x7f7c00cd9ba8, count=count@entry=0x7f7c00cd9ba4)
    at ../../src/xcb_conn.c:490
#6 0x00007f7c2b54f191 in _xcb_out_send (c=c@entry=0x7f7c0835d020, vector=vector@entry=0x7f7c00cd9be0, count=count@entry=1) at ../../src/xcb_out.c:367
#7 0x00007f7c2b54f8a7 in _xcb_out_flush_to (c=0x7f7c0835d020, request=93593) at ../../src/xcb_out.c:394
#8 0x00007f7c2b54f9c8 in xcb_take_socket (c=0x7f7c0835d020, return_socket=return_socket@entry=0x7f7c2e3cf000 <return_socket>, closure=closure@entry=0x7f7c0835b9e0,
    flags=0, sent=sent@entry=0x7f7c00cd9c78) at ../../src/xcb_out.c:293
#9 0x00007f7c2e3cea38 in require_socket (dpy=0x7f7c0835b9e0) at ../../src/xcb_io.c:68
#10 0x00007f7c2e3cf259 in _XFlush (dpy=0x7f7c0835b9e0) at ../../src/xcb_io.c:511
#11 0x00007f7c2e3d1c75 in _XGetRequest (dpy=dpy@entry=0x7f7c0835b9e0, type=type@entry=43 '+', len=len@entry=4) at ../../src/XlibInt.c:1735
#12 0x00007f7c2e3cb0bb in XSync (dpy=dpy@entry=0x7f7c0835b9e0, discard=discard@entry=0) at ../../src/Sync.c:43
#13 0x00007f7c2ed380ab in dri2XcbSwapBuffers (pdraw=0x7f7bd01085a0, remainder=<optimized out>, divisor=0, target_msc=0, dpy=0x7f7c0835b9e0)
    at ../../../../src/glx/dri2_glx.c:815
#14 dri2SwapBuffers (pdraw=0x7f7bd01085a0, target_msc=0, divisor=0, remainder=<optimized out>, flush=<optimized out>) at ../../../../src/glx/dri2_glx.c:853
#15 0x00007f7bf63bac5b in ?? () from /usr/lib/virtualbox/VBoxOGLrenderspu.so...