[Bug 787144] New: Memory leak in gstqtmux.c

Fri Sep 1 17:16:11 UTC 2017

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

            Bug ID: 787144
           Summary: Memory leak in gstqtmux.c
    Classification: Platform
           Product: GStreamer
           Version: 1.11.2
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: anton.nikolaevsky at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 358954
  --> https://bugzilla.gnome.org/attachment.cgi?id=358954&action=edit
proposed fix

Hello!

I have an application which takes video stream from IP camera and streams it as
video/mp4 through web-server. The application uses the following pipeline to
produce browsers-friendly mp4-stream:
    appsrc -> h264parse -> qtmux -> appsink

The problem is the application leaks GstBuffer-s steadily. AddressSanitizer
reports the following 2 stacks with direct leaks:

Direct leak of 43792 byte(s) in 161 object(s) allocated from:
    #0 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
    #1 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
    #2 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
    #3 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
    #4 0x7f978edcea05 in gst_buffer_new_allocate
gstreamer-1.11.2/gst/gstbuffer.c:846
    #5 0x7f97705743a8 in gst_h264_parse_wrap_nal
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:424
    #6 0x7f9770577c7b in gst_h264_parse_process_nal
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:889
    #7 0x7f977057a9e3 in gst_h264_parse_handle_frame
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1222
    #8 0x7f9770863093 in gst_base_parse_handle_buffer
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
    #9 0x7f977086ee72 in gst_base_parse_chain
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
    #10 0x7f978ee6cd74 in gst_pad_chain_data_unchecked
gstreamer-1.11.2/gst/gstpad.c:4205
    #11 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
    #12 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
    #13 0x7f97708aed19 in gst_base_src_loop
gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
    #14 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
    #15 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
    #16 0x7f978e667b9d in g_thread_pool_thread_proxy
glib-2.42.1/glib/gthreadpool.c:307
    #17 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
    #18 0x7f97c3b05063 in start_thread
/build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)

Direct leak of 8976 byte(s) in 33 object(s) allocated from:
    #0 0x7f97ca5ba73f malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
    #1 0x7f978e613f16 in g_malloc glib-2.42.1/glib/gmem.c:97
    #2 0x7f978e64b4ec in g_slice_alloc glib-2.42.1/glib/gslice.c:1007
    #3 0x7f978edce8b3 in gst_buffer_new gstreamer-1.11.2/gst/gstbuffer.c:798
    #4 0x7f97708d109f in gst_byte_writer_reset_and_get_buffer
gstreamer-1.11.2/libs/gst/base/gstbytewriter.c:244
    #5 0x7f9770581b0a in gst_h264_parse_handle_sps_pps_nals
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2306
    #6 0x7f9770582ccf in gst_h264_parse_pre_push_frame
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:2417
    #7 0x7f9770866ead in gst_base_parse_push_frame
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2455
    #8 0x7f9770865783 in gst_base_parse_handle_and_push_frame
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2337
    #9 0x7f9770868e5a in gst_base_parse_finish_frame
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2678
    #10 0x7f977057ac44 in gst_h264_parse_handle_frame
gst-plugins-bad-1.11.2/gst/videoparsers/gsth264parse.c:1248
    #11 0x7f9770863093 in gst_base_parse_handle_buffer
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:2145
    #12 0x7f977086ee72 in gst_base_parse_chain
gstreamer-1.11.2/libs/gst/base/gstbaseparse.c:3227
    #13 0x7f978ee6cd74 in gst_pad_chain_data_unchecked
gstreamer-1.11.2/gst/gstpad.c:4205
    #14 0x7f978ee6e76d in gst_pad_push_data gstreamer-1.11.2/gst/gstpad.c:4457
    #15 0x7f978ee6f73c in gst_pad_push gstreamer-1.11.2/gst/gstpad.c:4576
    #16 0x7f97708aed19 in gst_base_src_loop
gstreamer-1.11.2/libs/gst/base/gstbasesrc.c:2843
    #17 0x7f978eee4ede in gst_task_func gstreamer-1.11.2/gst/gsttask.c:335
    #18 0x7f978eee6e4f in default_func gstreamer-1.11.2/gst/gsttaskpool.c:69
    #19 0x7f978e667b9d in g_thread_pool_thread_proxy
glib-2.42.1/glib/gthreadpool.c:307
    #20 0x7f978e666eb6 in g_thread_proxy glib-2.42.1/glib/gthread.c:764
    #21 0x7f97c3b05063 in start_thread
/build/glibc-6V9RKT/glibc-2.19/nptl/pthread_create.c:309 (discriminator 2)

With help of additional logs in gst-plugins-good-1.11.2/gst/isomp4/gstqtmux.c
it was noticed that the buffers leak when the pipeline is about to stop (on
client disconnect) and there were some buffers in GstQTPad::fragment_buffers.
Unfortunately, I was not able to find the easy way 
to reproduce such conditions with simple gst-launch command line use-case
(tried filesrc and rtspsrc).

The proposed fix is attached.

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