GNOME Bugzilla – Bug 741900
gl: xcb threading assertion after some time
Last modified: 2016-11-15 07:39:39 UTC
$ env GST_GL_XINITTHREADS=1 gst-launch-1.0 videotestsrc ! queue ! tee name=t t. ! queue ! glvideomixer name=mixer sink_1::xpos=320 ! glimagesink t. ! queue ! glimagesink videotestsrc pattern=ball ! mixer. Running this for a few minutes gives: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'mixer': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... lt-gst-launch-1.0: ../../src/xcb_conn.c:186: write_vec: Assertion `!c->out.queue_len' failed. fish: 'env GST_GL_XINITTHREADS=1 gst-l…' terminated by signal SIGABRT (Abort)
+ Trace 234443
Thread 12 (Thread 0x7f484f7fe700 (LWP 17962))
Thread 11 (Thread 0x7f484ffff700 (LWP 17961))
Thread 10 (Thread 0x7f484effd700 (LWP 17963))
Thread 9 (Thread 0x7f4854f21700 (LWP 17960))
Thread 6 (Thread 0x7f484dffb700 (LWP 17965))
Thread 5 (Thread 0x7f484e7fc700 (LWP 17964))
Thread 2 (Thread 0x7f482e8cf700 (LWP 17970))
Thread 1 (Thread 0x7f482ffff700 (LWP 17968))
I cannot seem to be able to reproduce this. It honestly looks like a bug in libxcb/libx11 or maybe mesa's glx code. What version of libxcb/libx11/mesa do you have. If possible could you try the latest stable of each? I have libx11 - 1.6.2 libxcb - 1.11 mesa - 10.4.1
Still happens here libX11 1.6.2 libxcb 1.10 mesa 10.3.2 It only happens if there are multiple glimagesinks, if I replace one of them with a xvimagesink it doesn't crash.
Happens with mesa 10.4.2 too
This has been running fine for about 15 minutes now. libX11-dev 1.4.99.1-0ubuntu2.2 libxcb1-dev 1.8.1-1ubuntu0.2 libgl1-mesa-glx 8.0.4-0ubuntu0.7
Interestingly, I ^C it when I noticed it was still running in the background, and I got a SIGSEGV:
+ Trace 234944
$1 = {parent = {object = {object = {g_type_instance = {g_class = 0x1356a50}, ref_count = 0, qdata = 0x2}, lock = { p = 0x1356b20, i = {20278048, 0}}, name = 0x1331890 "gldisplayx11-0", parent = 0x0, flags = 0, control_bindings = 0x0, control_rate = 100000000, last_sync = 18446744073709551615, _gst_reserved = 0x0}, type = GST_GL_DISPLAY_TYPE_X11, priv = 0x1336490}, name = 0x0, display = 0x135b000, foreign_display = 0} diaplay_x11 seems to have lost its last ref by then.
Actually, this is in _finalize, so it's normal to have 0 refcount here I think, ignore that last comment.
Annoyingly, after rebuilding -bad, I don't see it anymore (and it was reliable). Instead, the wide window's left side now usually shows a flickering version of the right side, where it was showing a moving ball before the rebuild. But not always, from time to time, both show the moving ball, but way less smoothly that before the rebuild :S
These days this craps out in the intel driver in dri with a swap buffers or invalidate buffers or a 'something' buffers. mesa master also seems to fail with multiple drawables/surfaces to render into.
It's behaving perfectly now. It's been running for 10 minutes, smoothly, with no artifacts nor asserts/crashes.
Trying this now, I got a SIGSEGV once on ^C (no core to look at though), but that was a one off, I could not reproduce it again. No asserts.
All fine, libxcb 1.11.1, libX11 1.6.3, mesa-libglapi 11.1.0, both waiting minutes and with ^C.
I think we can close this as it was probably an issue with libxcb/mesa/something else.