GNOME Bugzilla – Bug 741381
rtph264pay: Race condition may cause crash when going from PAUSED->READY
Last modified: 2014-12-12 16:51:16 UTC
There is a thread race condition in rtph264pay which may cause unreffed buffers being used when sending SPS/PPS. The problem is that the pipeline thread may be running gst_rtp_h264_pay_handle_buffer simultaneously as some other thread is doing a state change which frees global data, rtph264pay->sps/pps, which is being used in handle_buffer. The result typically looks like this: GStreamer-CRITICAL **: gst_mini_object_unref: assertion `(g_atomic_int_get (&mini_object->lockstate) & LOCK_MASK) < 4' failed
Created attachment 292513 [details] [review] Call parents state change before doing downward state change. Suggested solution based on recommendation from Tim (on IRC) Call parent state change function before doing the downward state change.
Thanks for the patch. Pushed to master: commit 0a359cdbdce7d85b05582c988831db502793f828 Author: Patrick Radizi <patrickr@axis.com> Date: Thu Dec 11 10:16:06 2014 +0100 rtph264pay: fix potential crash when shutting down A race condition in the state change function may cause buffers to be unreffed while they are still used by the streaming thread in gst_rtp_h264_pay_send_sps_pps() resulting in a crash. Chain up to the parent class first in the state change function to make sure streaming has stopped and only then free those buffers. https://bugzilla.gnome.org/show_bug.cgi?id=741381 and cherry-picked into 1.4 branch.