After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767946 - vaapi: set NULL GstContext leads to segfaults
vaapi: set NULL GstContext leads to segfaults
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
1.8.2
Other Linux
: Normal critical
: 1.8.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-22 13:57 UTC by Julian Bouzas
Modified: 2016-06-24 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace (51.72 KB, text/plain)
2016-06-22 13:57 UTC, Julian Bouzas
  Details
backtrace2 (52.80 KB, text/plain)
2016-06-22 15:07 UTC, Julian Bouzas
  Details
vaapivideocontext: check if query context is NULL (1.14 KB, patch)
2016-06-24 10:10 UTC, Víctor Manuel Jáquez Leal
committed Details | Review
backtrace3 (52.90 KB, text/plain)
2016-06-24 10:50 UTC, Julian Bouzas
  Details
gstdebug.log (2.22 KB, text/x-log)
2016-06-24 11:13 UTC, Julian Bouzas
  Details

Description Julian Bouzas 2016-06-22 13:57:01 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.
Comment 1 Víctor Manuel Jáquez Leal 2016-06-22 14:29:18 UTC
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
Comment 2 Julian Bouzas 2016-06-22 15:07:56 UTC
Created attachment 330198 [details]
backtrace2
Comment 3 Julian Bouzas 2016-06-22 15:08:57 UTC
There you go, feel free to ask more info if you want more details.
Comment 4 Víctor Manuel Jáquez Leal 2016-06-24 09:51:27 UTC
(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 ???
Comment 5 Víctor Manuel Jáquez Leal 2016-06-24 10:10:35 UTC
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.
Comment 6 Víctor Manuel Jáquez Leal 2016-06-24 10:13:05 UTC
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
Comment 7 Julian Bouzas 2016-06-24 10:50:53 UTC
Created attachment 330308 [details]
backtrace3

backtrace with G_DEBUG=fatal-warnings and GST_DEBUG=GST_CONTEXT:5
Comment 8 Julian Bouzas 2016-06-24 10:51:44 UTC
Thanks a lot Victor, I will test the patch right now. I have attached the backtrace as well.
Comment 9 Víctor Manuel Jáquez Leal 2016-06-24 11:04:02 UTC
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!
Comment 10 Julian Bouzas 2016-06-24 11:13:09 UTC
Created attachment 330309 [details]
gstdebug.log

Log with G_DEBUG=fatal-warnings and GST_DEBUG=GST_CONTEXT:5,3
Comment 11 Julian Bouzas 2016-06-24 11:15:07 UTC
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?
Comment 12 Víctor Manuel Jáquez Leal 2016-06-24 11:22:55 UTC
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?
Comment 13 Víctor Manuel Jáquez Leal 2016-06-24 11:26:53 UTC
It's something triggered by decodebin, but what?
Comment 14 Víctor Manuel Jáquez Leal 2016-06-24 11:35:55 UTC
(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.
Comment 15 Julian Bouzas 2016-06-24 12:04:26 UTC
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.
Comment 16 Víctor Manuel Jáquez Leal 2016-06-24 14:04:40 UTC
(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.
Comment 17 Víctor Manuel Jáquez Leal 2016-06-24 14:25:09 UTC
Attachment 330307 [details] pushed as 80c4396 - vaapivideocontext: check if query context is NULL