GNOME Bugzilla – Bug 766940
vaapipostproc: race condition when updating src caps
Last modified: 2016-10-31 14:23:53 UTC
Created attachment 328633 [details] Reproducer of the bug When I continuously resize a running pipeline which decodes an H264 stream from the network, the pipline crashes after some time below libgstvaapi.so. If I don't use vaapi elements, the pipeline doesn't crash. I've written a reproducer which generate an H264 stream with the following pipeline: gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080 ! vaapih264enc ! h264parse config-interval=2 ! rtph264pay ! udpsink The program opens an X11 window which displays the video and always resizes it. After some time the program crashes. The decoding pipeline which is used looks like: udpsrc ! application/x-rtp,encoding-name=H264 ! rtph264depay ! decodebin ! vaapipostproc ! capsfilter ! appsink The resizing is done by inserting a probe at the source pad of decodebin and in the callback width and height of the capsfilter and vaapipostproc are changed. Regards, Thomas
Note to myself: To compile this gcc test.c -o test `jhbuild run pkg-config --cflags --libs gstreamer-1.0 gstreamer-app-1.0 gstreamer-video-1.0 x11` Now, I have tested the code and the code crashes in different places randomly, with several warning in the pad probes. I don't know what exactly to do. If you could to corner the issue would be very helpful.
To compile the source I use: gcc -o livescale livescale.c -g `pkg-config --libs --cflags gstreamer-1.0 gstreamer-video-1.0 gstreamer-app-1.0` -Wall -lX11 here is the backtrace of the crash. It looks always the same and happens only if vaapi is involved: (gdb) bt
+ Trace 236303
Created attachment 329236 [details] [review] [PATCH] GstVaapiPostproc: take ref on srccaps during transform There seems to be a race between gst_vaapipostproc_set_caps which releases postproc->allowed_srcpad_caps and gst_vaapipostproc_transform_caps which uses postproc->allowed_srcpad_caps. To see that this is in fact the case, here is a patch which takes a ref to the allowed caps in transform. With the patch I was able to run the test program for 4 hours without crashing. I believe the correct fix to the issue here is to add locking around the access to all of postproc's data members (there doesn't seem to be any locking in postproc currently).
(In reply to Scott D Phillips from comment #3) > Created attachment 329236 [details] [review] [review] > [PATCH] GstVaapiPostproc: take ref on srccaps during transform Nice! Thanks Scott!
(In reply to Scott D Phillips from comment #3) > I believe the correct fix to the issue here is to add locking around the > access to all of postproc's data members (there doesn't seem to be any > locking in postproc currently). Are you going to work on it? Perhaps using GST_OBJECT_LOCK() would be enough.
(In reply to Víctor Manuel Jáquez Leal from comment #5) > Are you going to work on it? > > Perhaps using GST_OBJECT_LOCK() would be enough. Yep, I'll take a crack at it today.
Created attachment 329345 [details] [review] [PATCH] vaapipostproc: add postproc_lock to protect data members (In reply to Víctor Manuel Jáquez Leal from comment #5) > > Perhaps using GST_OBJECT_LOCK() would be enough. In the end locking the element was going to be more complicated because ensure_display() also wants to lock the element when iterating over pads during the context query. So my patch introduces a new mutex instead (which seems to be what the other transform elements do for their caps transforming/setting functions).
Comment on attachment 329345 [details] [review] [PATCH] vaapipostproc: add postproc_lock to protect data members LGTM