[Bug 753539] mts: fix memory leak for files with embedded subtitles

[GStreamer (GNOME Bugzilla)]

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

Vineeth <vineeth.tm at samsung.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|subtitleoverlay: reorder    |mts: fix memory leak for
                   |creating colorspace         |files with embedded
                   |elements to fix memory leak |subtitles

--- Comment #3 from Vineeth <vineeth.tm at samsung.com> ---

   Any mts file with embedded subtitles will do..

   I tested with a file downloaded from
https://archive.org/details/scm-10794-mtstestfile, named H.264/MPEG2-TS

G_SLICE=always-malloc GST_DEBUG=gc-friendly valgrind --tool=memcheck
--leak-check=full --show-leak-kinds=definite --trace-children=yes
--suppressions=gstreamer/common/gst.supp gst-play-1.0
/home/vineethtm/gst/master/00007.mts

   There are basically three different leaks.

1) This is mentioned above.

   This leak happens because in gstdvdspu.c, gst_dvd_spu_src_event, peer of
sink pad is being checked and if present it is forwarded. Without the change in
above patch sink pad wont be present and hence the event will be leaked.
   This can simply be fixed by unref'ing the event in else case. I am attaching
patch next for this as well. I feel both the patches are needed and valid.
Because it is always better to create and link the sink pad to renderer(dvdspu
here) first and then create the src pad.


2) Leak of buffer.
==29969== 54,148 (3,876 direct, 50,272 indirect) bytes in 51 blocks are
definitely lost in loss record 6,555 of 6,562
==29969==    at 0x402C17C: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==29969==    by 0x433EBE2: g_malloc (in
/lib/i386-linux-gnu/libglib-2.0.so.0.4002.0)
==29969==    by 0x4355281: g_slice_alloc (in
/lib/i386-linux-gnu/libglib-2.0.so.0.4002.0)
==29969==    by 0x4185E7F: gst_memory_new_wrapped (gstallocator.c:391)
==29969==    by 0x4190C94: gst_buffer_new_wrapped_full (gstbuffer.c:858)
==29969==    by 0x4190E04: gst_buffer_new_wrapped (gstbuffer.c:883)
==29969==    by 0x6EF87F6: gst_ts_demux_push_pending_data (tsdemux.c:2180)
==29969==    by 0x6EFB2B3: gst_ts_demux_push (tsdemux.c:2316)
==29969==    by 0x6EF34E8: mpegts_base_chain (mpegtsbase.c:1145)
==29969==    by 0x6EF3765: mpegts_base_loop (mpegtsbase.c:1322)
==29969==    by 0x41FE4C8: gst_task_func (gsttask.c:331)
==29969==    by 0x41FF66E: default_func (gsttaskpool.c:68)

This happens because in gstspu-pgs, gstspu_exec_pgs_buffer()
buffer is being mapped, but not being unmapped.
Attaching a patch for this as well.



3) Leak related to deinterlace/ORC
==6292== 40 bytes in 1 blocks are definitely lost in loss record 4,782 of 6,558
==6292==    at 0x402C17C: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==6292==    by 0x145BC4E6: orc_program_new (in
/usr/lib/i386-linux-gnu/liborc-0.4.so.0.18.0)
==6292==    by 0x145BC534: orc_program_new_from_static_bytecode (in
/usr/lib/i386-linux-gnu/liborc-0.4.so.0.18.0)
==6292==    by 0x145855ED: deinterlace_line_linear (tmp-orc.c:478)
==6292==    by 0x14584884: deinterlace_scanline_linear_planar_y_c (linear.c:54)
==6292==    by 0x14554BFB:
gst_deinterlace_simple_method_deinterlace_frame_planar_plane
(gstdeinterlacemethod.c:511)
==6292==    by 0x14555AF2:
gst_deinterlace_simple_method_deinterlace_frame_planar
(gstdeinterlacemethod.c:557)
==6292==    by 0x1455522E: gst_deinterlace_method_deinterlace_frame
(gstdeinterlacemethod.c:199)
==6292==    by 0x1454EE35: gst_deinterlace_output_frame (gstdeinterlace.c:1914)
==6292==    by 0x145532AE: gst_deinterlace_chain (gstdeinterlace.c:2075)
==6292==    by 0x41C961F: gst_pad_push_data (gstpad.c:4040)
==6292==    by 0x464E625: gst_base_transform_chain (gstbasetransform.c:2372)

Not sure how to fix this. This might be related to orc and probably needs to be
supressed.

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