GNOME Bugzilla – Bug 767437
segfault in gst_element_set_context_default (through vaapi)
Last modified: 2016-06-23 10:45:18 UTC
When trying to stream from remote RTSP-server, quite often I'm seeing a segfault while connecting / try to start the stream; from the backtrace I think VAAPI is the culprit. I can reproduce this fairly easy, simply using something like gst-play-1.0 rtsp://.... and warnings: Now playing rtsp://192.168.100.23:554/stream Pipeline is live. WARNING Could not read from resource. WARNING debug information: gstrtspsrc.c(4847): gst_rtspsrc_reconnect (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source: Could not receive any UDP packets for 5,0000 seconds, maybe your firewall is blocking it. Retrying using a TCP connection. libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 ** (gst-play-1.0:12694): CRITICAL **: gst_vaapi_video_context_get_display: assertion 'GST_IS_CONTEXT (context)' failed (gst-play-1.0:12694): GStreamer-CRITICAL **: gst_context_get_context_type: assertion 'GST_IS_CONTEXT (context)' failed (gst-play-1.0:12694): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed (gst-play-1.0:12694): GStreamer-CRITICAL **: gst_context_get_context_type: assertion 'GST_IS_CONTEXT (context)' failed Note, I'm using gstreamer from git, except for gst-vaapi from Fedora 24; I have seen the same problem with the Fedora-provided gstreamer (1.8.1) as well. The actual crash is in gst_element_set_context_default. element->contexts is a list of 1 element, however, the element data is NULL, which strcmp does not appreciate. gdb% frame 1
+ Trace 236314
Oh, here's part of the debugging session: gdb% frame 1
+ Trace 236315
Thanks for reporting this. Can you run G_DEBUG=fatal-warnings gdb --args gst-play-1.0 rtsp://192.168.100.23:554/stream And post the backtrace??? I would like to know why the vaapi elements are receiving a NULL context.
*** Bug 767452 has been marked as a duplicate of this bug. ***
Victor, I am trying to run my program with G_DEBUG=fatal-warnings, but I don't seem to get any output.
(In reply to Sergio Torres Soldado (zenx) from comment #4) > Victor, > > I am trying to run my program with G_DEBUG=fatal-warnings, but I don't seem > to get any output. Hi Sergio, Also thank you for taking your time to sort this out. Could you paste the console output (the "libva info" messages and so on)?
Ah, could you tell which versions of gstreamer and gstreamer-vaapi are you using?
They are all from the 1.8.1 release.
Created attachment 329482 [details] Platform info
Created attachment 329540 [details] GST_DEBUG log
Created attachment 329541 [details] Backtrace with G_DEBUG
Created attachment 329558 [details] [review] backport patch from master @Sergio, @djcb Could you apply this patch and check if it fixes the crash?
(In reply to Víctor Manuel Jáquez Leal from comment #11) > Created attachment 329558 [details] [review] [review] > backport patch from master > > @Sergio, @djcb > > Could you apply this patch and check if it fixes the crash? Hi Victor, Thank you for your help. The problem still occurs but much less often, I don't have a deterministic way of reproducing the bug. It seems to occur when I create a large number of pipelines (>10), I don't know if it is a driver limitation or something related. I will continue testing.
Just in case, is fatal-warnings really effective ? I am always using a '_', not a '-' in between.
@victor: thanks for looking into so quickly! I tried with gst-vaapi (git/master), and haven't been able to reproduce so far. However, it seems that the crash only happpened with certain (local) rtsp servers, and since those have changed, perhaps the same paths aren't hit anymore.
Below is the backtrace with fatal-warnings; and I can confirm that I can reproduce this with 1.8.1, but not with master - so seems it's fixed already. gdb% bt
+ Trace 236333
(In reply to djcb from comment #15) > Below is the backtrace with fatal-warnings; and I can confirm that I can > reproduce this with 1.8.1, but not with master - so seems it's fixed already. Did you apply the posted patch? I guess not. But it looks like the needed patch. Slomo is going to kill me, since 1.8.2 was done last week :(
I'm sure there'll be a 1.8.3 :)
(In reply to Sergio Torres Soldado (zenx) from comment #12) > Thank you for your help. The problem still occurs but much less often, I > don't have a deterministic way of reproducing the bug. It seems to occur > when I create a large number of pipelines (>10), I don't know if it is a > driver limitation or something related. I will continue testing. I'm going to push this patch to branch 1.8 aiming release 1.8.3 @Sergio, let me know if you can still reproduce the bug.
Comment on attachment 329558 [details] [review] backport patch from master commited commit c211403af94fdef90394f60944c5d6d7be3b1e62 Author: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> Date: Thu Apr 21 12:57:30 2016 +0200
Closing the bug. If it remains reproducible, let's reopen this bug.