GNOME Bugzilla – Bug 729257
glvideomixer: segfault in gst_gl_video_mixer_callback when accessing frame info
Last modified: 2014-05-27 03:58:28 UTC
On OS X 10.9 with gst-plugins-bad built from cerbero from 967982a0b5362d500081d3353667e089b996641b , if I try to run the following pipeline, I observe a segfault: gst-launch-1.0 mix. ! queue ! glimagesink \ gltestsrc pattern=black ! video/x-raw,width=1280,height=800 ! queue name=background \ avfvideosrc device-index=0 ! video/x-raw,width=1280,height=720 ! glcolorscale ! video/x-raw,width=640,height=720 ! queue name=left \ avfvideosrc device-index=0 ! video/x-raw,width=1280,height=720 ! glcolorscale ! video/x-raw,width=640,height=720 ! queue name=right \ background. ! mix.sink_0 \ left. ! mix.sink_1 \ right. ! mix.sink_2 glvideomixer name=mix sink_2::xpos=640 Output and backtrace: Current executable set to 'gst-launch-1.0' (x86_64). (lldb) r Process 90503 launched: '/path/to/bin/gst-launch-1.0' (x86_64) Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Got context from element 'glimagesink0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)NULL; Setting pipeline to PLAYING ... New clock: GstSystemClock (gst-launch-1.0:90503): GStreamer-CRITICAL **: guint64 _gst_util_uint64_scale_int(guint64, gint, gint, gint): assertion 'denom > 0' failed (gst-launch-1.0:90503): GStreamer-CRITICAL **: guint64 _gst_util_uint64_scale_int(guint64, gint, gint, gint): assertion 'denom > 0' failed Process 90503 stopped * thread #17: tid = 0x10e53b, 0x0000000101812e93 libgstopengl.so`gst_gl_video_mixer_callback(stuff=<unavailable>) + 1091 at gstglvideomixer.c:243, stop reason = EXC_BAD_ACCESS (code=1, address=0x220) frame #0: 0x0000000101812e93 libgstopengl.so`gst_gl_video_mixer_callback(stuff=<unavailable>) + 1091 at gstglvideomixer.c:243 240 count++; 241 continue; 242 } -> 243 in_width = GST_VIDEO_INFO_WIDTH (&frame->pad->in_info); 244 in_height = GST_VIDEO_INFO_HEIGHT (&frame->pad->in_info); 245 246 if (!frame->texture || in_width <= 0 || in_height <= 0) { (lldb) bt * thread #17: tid = 0x10e53b, 0x0000000101812e93 libgstopengl.so`gst_gl_video_mixer_callback(stuff=<unavailable>) + 1091 at gstglvideomixer.c:243, stop reason = EXC_BAD_ACCESS (code=1, address=0x220) * frame #0: 0x0000000101812e93 libgstopengl.so`gst_gl_video_mixer_callback(stuff=<unavailable>) + 1091 at gstglvideomixer.c:243 frame #1: 0x000000010185fadf libgstgl-1.0.0.dylib`gst_gl_framebuffer_use_v2(frame=<unavailable>, texture_fbo_width=1280, texture_fbo_height=800, fbo=8, depth_buffer=<unavailable>, texture_fbo=19, cb=<unavailable>, stuff=<unavailable>) + 287 at gstglframebuffer.c:307 frame #2: 0x000000010185e816 libgstgl-1.0.0.dylib`_use_fbo_v2(context=<unavailable>, data=<unavailable>) + 54 at gstglutils.c:419 frame #3: 0x000000010185d12d libgstgl-1.0.0.dylib`_run_message_sync(message=0x0000000103f44568) + 29 at gstglwindow.c:341 frame #4: 0x00007fff9164613e Foundation`__NSThreadPerformPerform + 229 frame #5: 0x00007fff86dfa661 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 frame #6: 0x00007fff86debd12 CoreFoundation`__CFRunLoopDoSources0 + 242 frame #7: 0x00007fff86deb49f CoreFoundation`__CFRunLoopRun + 831 frame #8: 0x00007fff86deaf25 CoreFoundation`CFRunLoopRunSpecific + 309 frame #9: 0x00007fff9164badc Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 253 frame #10: 0x0000000101861190 libgstgl-1.0.0.dylib`gst_gl_window_cocoa_run(window=<unavailable>) + 240 at gstglwindow_cocoa.m:283 frame #11: 0x0000000101845df4 libgstgl-1.0.0.dylib`gst_gl_context_create_thread(context=0x0000000103009be0) + 2580 at gstglcontext.c:843 frame #12: 0x0000000100235e8a libglib-2.0.0.dylib`g_thread_proxy(data=0x000000010200b050) + 90 at gthread.c:798 frame #13: 0x00007fff8cf46899 libsystem_pthread.dylib`_pthread_body + 138 frame #14: 0x00007fff8cf4672a libsystem_pthread.dylib`_pthread_start + 137
As a note, this works with two gltestsrc inputs, but not with two avfvideosrc inputs.
So the issue here seems to be that in gst_gl_mixer_process_textures, mixcol->buffer is NULL so no processing occurs with the buffer before being passed to the subclass resulting in a NULL frame->pad. Can also be reproduced with v4l2src inputs.
What is supposed to happen? Is mixcol->buffer supposed to be populated?
Yes, by gst_gl_mixer_fill_queues().
commit 397928714dbc6c8d70d2c56deeed1802a0020252 Author: Matthew Waters <ystreet00@gmail.com> Date: Tue May 27 13:55:15 2014 +1000 gl/mixer: don't segfault when we don't have a buffer https://bugzilla.gnome.org/show_bug.cgi?id=729257