GNOME Bugzilla – Bug 741271
rtph264pay: Buffer leak in H.264 payloader when using SPS/PPS
Last modified: 2014-12-16 14:19:24 UTC
When using the rtph264pay element a buffer will leak if the pipeline is shutdown when a SPS/PPS header is being created. It's the buffer that would follow the SPS/PPS that is leaked.
Created attachment 292331 [details] [review]
Add missing unref in error handling.
Author: Patrick Radizi <firstname.lastname@example.org>
Date: Mon Dec 8 21:26:18 2014 +0100
rtph264pay: Fixes buffer leak when using SPS/PPS
Fixes a buffer leak that would occurr if the pipeline was shutdown
while a SPS/PPS header was being created.
I just did some more tests and now it chrashed with the patch. I need to investigate it further
How does it crash for you? The patch seems correct, paybuf is unreffed (or taken over into the outbuf) in all other code paths, so would be leaked here on errors.
I thought it was ok to, but now it chrashes in gst_rtp_h264_pay_send_sps_pps:749 when it's inserting the PPS
GStreamer-CRITICAL **: gst_mini_object_unref: assertion `(g_atomic_int_get (&mini_object->lockstate) & LOCK_MASK) < 4' failed
I think the patch is ok. The problem seems to be that it changes the timing so that an 'old' bug is triggered. It only happens sometimes and is dependant on the debug level used.
I think that the commit 53ffd9e1cab086f334f94597973fdb0fcb175adc is the cause. Because of this commit two threads are simultaneously using rtph264pay->sps and rtph264pay->pps. One is the pipeline thread running in gst_rtp_h264_pay_send_sps_pps the other the thread doing the state change and calling gst_rtp_h264_pay_clear_sps_pps when going from paused to ready.
Perhaps I'm missing something but I don't really understand why the return value of gst_rtp_h264_pay_payload_nal is ignored in gst_rtp_h264_pay_send_sps_pps, isn't this the cause of this problem?
I have created a new bug report of the chrash since it is a separate issue and that problem existed before:
The patch in this bug report (Comment 1) is thus ok and 'Comment 3' can be ignored.