GNOME Bugzilla – Bug 724806
SEGFAULT in gstgldownload
Last modified: 2014-02-24 13:37:19 UTC
This segmentation fault appears sometimes on my platform (i965). Reproduction rate : 1/4 Backtrace :
+ Trace 233199
Environment informations : GST Version : 1.2.4 External informations : Video sample : http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv Code sample : http://pastebin.com/0eUBHi6X Code informations : Display in multiple context a h264 video stream through vaapi, openGL and xvimagesink.
Mailing list entry : http://gstreamer-devel.966125.n4.nabble.com/Multiple-pipeline-with-OpenGL-and-vaapi-elements-td4665379.html#a4665399
I forgot to add the gstreamer debug output : 0:00:00.212480698 ERROR default gstglutils.c:87:gst_gl_context_check_framebuffer_status: General FBO error 0:00:00.212582758 ERROR default gstglutils.c:87:gst_gl_context_check_framebuffer_status: General FBO error 0:00:00.212597018 WARN default gstglutils.c:353:gst_gl_context_set_error: GL framebuffer status incomplete
What Mesa version do you have? Recent mesa (10.x) glsl compiler is not thread safe any more. See https://bugs.freedesktop.org/show_bug.cgi?id=69200 and https://bugs.freedesktop.org/show_bug.cgi?id=69890
OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.2 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.2 OpenGL shading language version string: 1.30 OpenGL context flags: (none)
The method glCheckFramebufferStatus failed with a 0 in this case. Add a proper error handling in gstgldownload line 644 avoid the SIgFAULT signal but generate a green frame on the output.
Created attachment 269879 [details] [review] Patch for correct error handling in gstgldownload.c
I got more informations using the lastest version of gst-plugin-gl : This is the gstreamer debug output : 0:00:00.246154721 vaapivideomemory gstvaapivideomemory.c:167:gst_video_meta_map_vaapi_memory: unsupported map flags (0x1) 0:00:00.246203976 default video-frame.c:136:gst_video_frame_map_id: failed to map video frame plane 0 0:00:00.246218897 glupload gstglupload.c:647:gst_gl_upload_perform_with_buffer:<GstGLUpload@0x7fdd8c00d3b0> Failed to map memory ** (POC_DISPLAY:13123): CRITICAL **: gst_vaapi_image_get_plane: assertion '_gst_vaapi_image_is_mapped(image)' failed ** (POC_DISPLAY:13123): CRITICAL **: gst_vaapi_image_get_pitch: assertion '_gst_vaapi_image_is_mapped(image)' failed 0:00:00.247255584 default gstglutils.c:87:gst_gl_context_check_framebuffer_status: General FBO error 0:00:00.247297197 default gstglutils.c:87:gst_gl_context_check_framebuffer_status: General FBO error 0:00:00.247306409 default gstglutils.c:353:gst_gl_context_set_error: GL framebuffer status incomplete ** (POC_DISPLAY:13123): CRITICAL **: gst_gl_shader_compile: assertion 'priv->program_handle' failed So, I tried to reproduce the problem without using vaapidecode element, and It seems to work correctly. Now, I'm not a expert, but this unexcepted behavior may be cause by the vaapidecode element.
The path (commited by Matthew) resolve the critical failure in the gst-plugin-gl side. The bug is reported to vaapi https://bugzilla.gnome.org/show_bug.cgi?id=725058. The bug against OpenGL elements is fix.