GNOME Bugzilla – Bug 754198
glimagesink: Xlib / xcb assertion with client-draw signal
Last modified: 2016-11-15 05:24:44 UTC
Created attachment 310128 [details] C testcase The attached testcase loops through a single video file (creates and deletes pipeline each time, there is no seek/re-use of pipeline) The main() function calls XInitThread() right at its beginning. The app renders in its own GLFW window using libglfw3 (receiving samples/textures from glimagesink's client-draw callback). The application context is shared with each pipeline through bus sync-message (GST_MESSAGE_NEED_CONTEXT) Often the app aborts with xcb/xlib assertion: [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. info-beamer: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. The error can happen from : - gst_gl_context_create_thread / gst_gl_context_glx_create_context / glXCreateContextAttribsARB - libglfw.so.3 / XPending Application's X11 display/context is used to create a GstGLcontext/GstGLDisplay (done only once in the beginning of main) Also following (non-aborting) Xlib message is seen sometimes: Xlib: sequence lost (0x100b7 > 0xba) in reply type 0x0! Is something obviously wrong in the testcase? Is the XInitThreads() call supposed to take care of this? Also tried with GST_GL_XINITTHREADS=1, same results.
Created attachment 310129 [details] backtrace 1
Created attachment 310130 [details] backtrace 2
Also crashes on GLX with Intel driver here: GST_GL_XINITTHREADS=1 gst-launch-1.0 videotestsrc ! glimagesink videotestsrc ! glimagesink videotestsrc ! glimagesink videotestsrc ! glimagesink videotestsrc ! glimagesink videotestsrc ! glimagesink Which driver are you using, Vasilis? And where does the libglfw.so.3 usage come from, we don't use glfw in GStreamer. Is that from your application?
I am using radeon driver. Glfw3 is from the application only. Perhaps I can reproduce the problem without glfw (maybe use GTK in application) Pipeline with multiple glimagesink elements: gst-launch-1.0 videotestsrc ! glimagesink videotestsrc ! glimagesink crashes only when GST_GL_XINITTHREADS is undefined. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gst-launch-1.0: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. With GST_GL_XINITTHREADS=1 it works on radeon.
I have same crash as in comment 3 (Intel driver).
For what its worth, I cannot reproduce with gtkglsink, GST_GL_XINITTHREADS=1 gst-launch-1.0 videotestsrc ! glsinkbin sink=gtkglsink videotestsrc ! glsinkbin sink=gtkglsink videotestsrc ! glsinkbin sink=gtkglsink videotestsrc ! glsinkbin sink=gtkglsink videotestsrc ! glsinkbin sink=gtkglsink videotestsrc ! glsinkbin sink=gtkglsink
Just a comment that commit e96431e9b may exacerbate the possibility of threading assertion because it now calls glXCreateContextAttribsARB more times (for each possible gl version counting down) during gstglcontext creation. But the commit is fine, not the cause of the problem.
(In reply to Sebastian Dröge (slomo) from comment #3) > Also crashes on GLX with Intel driver here: > > GST_GL_XINITTHREADS=1 gst-launch-1.0 videotestsrc ! glimagesink > videotestsrc ! glimagesink videotestsrc ! glimagesink videotestsrc ! > glimagesink videotestsrc ! glimagesink videotestsrc ! glimagesink That's Intel driver brokeness as it lacks the required thread safety/NULL checks for multiple contexts drawing to multiple surfaces/windows on multiple threads. gtkglsink works because all back buffer updates occur on a the main thread so are serialized. @Vasilis: In display_x11_init() you should call gst_gl_display_filter_gl_api (gl_display, GST_GL_API_OPENGL) to limit the requested GL api so that gstgl doesn't attempt to create a gl3 context shared with a legacy gl context.
This this is all actually NOTABUG? Did someone report the brokeness to the Intel driver people?
Ok, I'm working on a bug report for the intel crash. It looks like some debugging is required for the radeon issue. I'm not exactly sure where that's coming from. Vasilis, could you try adding an XSynchonize(display, True) call into both gst-libs/gst/gl/x11/gstgldisplay_x11.c and gst-libs/gst/gl/x11/gstglwindow_x11.c directly after XOpenDisplay is called anywhere and get new backtraces.
Intel bug report https://bugs.freedesktop.org/show_bug.cgi?id=91860
(In reply to Matthew Waters from comment #10) > Ok, I'm working on a bug report for the intel crash. > > It looks like some debugging is required for the radeon issue. I'm not > exactly sure where that's coming from. Vasilis, could you try adding an > XSynchonize(display, True) call into both > gst-libs/gst/gl/x11/gstgldisplay_x11.c and > gst-libs/gst/gl/x11/gstglwindow_x11.c directly after XOpenDisplay is called > anywhere and get new backtraces. With XSynchonize(display, True) after XOpenDisplay() calls in the files above, I still get same kinds of backtraces: - from _create_context_with_flags (same as backtrace 1), but these are less frequent now, perhaps due to the synchronize calls. They have happened rarely though. - Many backtraces are from glfwPollEvents or glfwSwapbuffer, so this may be a libglfw3 problem (although the testcase calls XInitThreads first thing in main function) e.g. (gdb) bt
+ Trace 235419
Thread 140735700510464 (LWP 7685)
These are with: libx11 - 1.6.2 libxcb - 1.11 mesa - 10.7.1 or 11.1 libdrm - 2.4.64 linux - 3.19.0 (i will try with newer kernel) I use libxcb-1.1 because of a bug in libxcb-1.0 (../../src/xcb_conn.c:186: write_vec: Assertion `!c->out.queue_len' failed). See also https://bugzilla.gnome.org/show_bug.cgi?id=741900
There are some refcounting issues in the test application that may or may not contribute to this issue. Running with GST_TRACE=mem-live uncovers many objects that have not been unreffed including some samples/buffers and a GL context from each loop of the video (probably due to the leak of samples).
Apart from the obvious use-after-free backtraces I get from the example, there doesn't seem to any actionable items here that don't involve fixing drivers. Closing.