[Bug 787144] Memory leak in gstqtmux.c

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=787144

--- Comment #2 from Anton Nikolaevsky <anton.nikolaevsky at gmail.com> ---
Hello Sebastian! 
Thanks for your reply.
I've just figured out that I forgot about qtmux attributes my application sets: 

    fragment-duration=100 faststart=1

So now I'm able to reproduce the leak with simple gst-launch command:

    gst-launch-1.0 rtspsrc location=rtsp://url ! queue ! rtph264depay !
h264parse config-interval=-1 ! qtmux fragment-duration=100 faststart=1 !
filesink location=out.mp4

Moreover, I've found that the leak does not reproduce when filesrc is used,
i.e.:

    gst-launch-1.0 filesrc location=/home/builder/10.mp4 ! qtdemux ! h264parse
config-interval=-1 ! qtmux fragment-duration=100 faststart=1 ! filesink
location=out.mp4

It turned out that the difference was in EOS. filesrc sends EOS automatically
on EOF. When pipeline with rtspsrc is interrupted with SIGINT, EOS is not sent
by default and the leak is observed.
So the workaround is to force EOS generation on shut down:

    gst-launch-1.0 --eos-on-shutdown rtspsrc location=rtsp://url ! queue !
rtph264depay ! h264parse config-interval=-1 ! qtmux fragment-duration=100
faststart=1 ! filesink location=out.mp4

I've checked the originally proposed fix with gst-launch command.
Unfortunately, gst-launch crashes with heap-use-after-free (on gst_buffer_unref
called on already freed object). It looks like there is a data race around
GstQTPad::fragment_buffers between gst_qt_mux_pad_reset invoked during pipeline
shutdown chain and gst_qt_mux_pad_fragment_add_buffer still using it in
different thread.
I believe the data race can be eliminated by making access to
GstQTPad::fragment_buffers atomic either with proper synchronization or with
some lock-free technique.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.