GNOME Bugzilla – Bug 767946
vaapi: set NULL GstContext leads to segfaults
Last modified: 2016-06-24 14:27:09 UTC
Created attachment 330192 [details] backtrace Hi there, When the rtspsrc element cannot receive any UDP packets for 5s and fallbacks to TCP, the vaapi h264 decoder segfaults if it is used with decodebin. gst-launch-1.0 rtspsrc location=<rtsp-source-that-takes-more-than-5s-to-send-UDP-packets> ! decodebin ! fakesink ... Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a TCP connection. ** (gst-launch-1.0:2047): CRITICAL **: gst_vaapi_video_context_get_display: assertion 'GST_IS_CONTEXT (context)' failed (gst-launch-1.0:2047): GStreamer-CRITICAL **: gst_context_get_context_type: assertion 'GST_IS_CONTEXT (context)' failed (gst-launch-1.0:2047): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 (gst-launch-1.0:2047): GStreamer-CRITICAL **: gst_context_get_context_type: assertion 'GST_IS_CONTEXT (context)' failed Caught SIGSEGV ... However, if we create the elements manually without using decodebin, the decoder works fine and plays the pipeline: gst-launch-1.0 rtspsrc location=<rtsp-source-that-takes-more-than-5s-to-send-UDP-packets> ! rtph264depay ! h264parse ! vaapidecode ! fakesink Since the error shows something about the *vaapi context*, I thought this would be related to the following issue: https://bugzilla.gnome.org/show_bug.cgi?id=767437. However, after applying the patch, I still get the same error :( I have attached the backtrace when it segfaults.
Thanks. Would you upload a backtrace with the environment variable G_DEBUG=fatal-warnings ??? I need to know why we are receiving a corrupted GstContext. Thanks
Created attachment 330198 [details] backtrace2
There you go, feel free to ask more info if you want more details.
(In reply to Julian Bouzas from comment #3) > There you go, feel free to ask more info if you want more details. Would you run it again with G_DEBUG=fatal-warnings and GST_DEBUG=GST_CONTEXT:5 ???
Created attachment 330307 [details] [review] vaapivideocontext: check if query context is NULL Under certain conditions the element might receive a positive context query but without a context instance. This situation will lead to a segmentation fault when traversing the context list in the pipeline.
Julian, Could you test this patch, just to see if it fixes the problem. Nonetheless, it looks to me that the problem is in other place, because the query should not return TRUE without any context in it. That's why I also need the log asked in comment 4
Created attachment 330308 [details] backtrace3 backtrace with G_DEBUG=fatal-warnings and GST_DEBUG=GST_CONTEXT:5
Thanks a lot Victor, I will test the patch right now. I have attached the backtrace as well.
Sorry, I didn't say it explicitly, what I need is a log, not a backtrace. G_DEBUG=fatal-warnings gst-launch-1.0 rtspsrc location=<rtsp-source-that-takes-more-than-5s-to-send-UDP-packets> ! decodebin ! fakesink --gst-debug=GST_CONTEXT:5,3 --gst-debug-no-color 2>&1 > gstdebug.log In order to know why a NULL context is shared through the query. Thanks Julian!
Created attachment 330309 [details] gstdebug.log Log with G_DEBUG=fatal-warnings and GST_DEBUG=GST_CONTEXT:5,3
No worries, I just attached the log now. I also tested your patch and it fixes the issue \o/ Thanks a lot for that, do you think it is the proper fix?
One more log (without the patch), please :) G_DEBUG=fatal-warnings and GST_DEBUG=5 Is going to be big, but I need to know why we are receiving a NULL context from upstream. @Sebastian, can you shed some light here?
It's something triggered by decodebin, but what?
(In reply to Julian Bouzas from comment #11) > I also tested your patch and it fixes the issue \o/ Yei!! :D > Thanks a lot for that, do you think it is the proper fix? I don't know. It doesn't feel right. As far as I understand, we would be hiding another problem since we shouldn't receive a NULL context in a query's reply.
I cannot attach the log in bugzilla as the file is too big so I sent you an email with it. Also, I cannot share the rtsp stream due to company policies. however, if you really want to reproduce the bug I can ask them to set up a test rtsp stream for you.
(In reply to Julian Bouzas from comment #15) > I cannot attach the log in bugzilla as the file is too big so I sent you an > email with it. > > Also, I cannot share the rtsp stream due to company policies. however, if > you really want to reproduce the bug I can ask them to set up a test rtsp > stream for you. Thanks Julian. If I understand correctly, the problem is in vaapidecodebin, where the bin changes its state to READY when the bin internals are still incomplete. Hence, vaapidecode request for the GstVaapiDisplay when it doesn't have a neighbor. I'll push this patch, but for the release 1.10 I'm working in a re-design of vaapidecodebin, though my plan for 1.12 is to deprecate vaapidecodebin and theach to decodebin3 to use vaapipostproc if it is available.
Attachment 330307 [details] pushed as 80c4396 - vaapivideocontext: check if query context is NULL