[Bug 674801] New: tsdemux: more memory leaks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=674801
  GStreamer | gst-plugins-bad | git

           Summary: tsdemux: more memory leaks
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: hk at getslash.de
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=212789)
 View: https://bugzilla.gnome.org/attachment.cgi?id=212789
 Review: https://bugzilla.gnome.org/review?bug=674801&attachment=212789

Don't leak buffers when hitting PES header parsing errors

tsdemux (0.10) leaks memory in some cases (with fixes from end of
march/begginning of april included!). On live mpegts streams (DVB-S) we have
seen about 15mb/min for some streams (Arte with 4 mpeg2 streams). It seems to
happen only in streams with multiple audio-streams wheres single-audio streams
don't seem to leak. When compared to pipelines with mpegtsdemux instead of
tsdemux the same streams (and pipelines) don't show any leaks. Can be verified
with a simple gst-launch playbin2 ... pipe.

Does not seem to be related to UNLINKED pads (tested with pads connected to
input-selector with always-ok=TRUE/FALSE).

There are at least 2 sources of the leaks, with one identfied and attached
patch:

1. Leaked buffers on PES header parsing erros as reported by valgrind's
memcheck:

==25074== 398,728 (336,904 direct, 61,824 indirect) bytes in 3,662 blocks are
definitely lost in loss record 5,247 of 5,248
==25074==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==25074==    by 0x41C4B03: g_malloc (gmem.c:164)
==25074==    by 0x41DC8B0: g_slice_alloc (gslice.c:842)
==25074==    by 0x41DCB74: g_slice_alloc0 (gslice.c:854)
==25074==    by 0x415E8C6: g_type_create_instance (gtype.c:1869)
==25074==    by 0x40AC1E4: gst_mini_object_new (gstminiobject.c:217)
==25074==    by 0x40847CF: gst_buffer_new (gstbuffer.c:503)
==25074==    by 0x4085215: gst_buffer_create_sub (gstbuffer.c:761)
==25074==    by 0x50A50A1: gst_adapter_take_buffer (gstadapter.c:700)
==25074==    by 0x60ACFFF: mpegts_packetizer_next_packet
(mpegtspacketizer.c:2310)
==25074==    by 0x60A5FDF: mpegts_base_chain (mpegtsbase.c:1382)
==25074==    by 0x60A657A: mpegts_base_loop (mpegtsbase.c:1558)

Tracing down buffer pointers revealed leaked buffers on "Error parsing PES
header ...". The attached patch fixes this leak for us. As the tsdemux codebae
is new to me, you should verify that this has no side effects ;-) Thanks!

This problem can be reproduced with a simple pipeline like

gst-launch filesrc location=/mnt/ltmp/vid/arte.ts ! tsdemux name=demux ! queue 
! mad ! autoaudiosink demux. ! queue ! mpeg2dec ! xvimagesink demux.

on the following captured stream:
http://www.math.uni-bielefeld.de/~hkaelber/vid/leak.ts

2. With this patch there are still smaller leaks (6MB/min) on some live streams
with >1 audio stream (Arte, Pro7). These leaks seem to only show up on live
streams. Could not yet reproduce with captured streams played back via filesrc.
Still searching ... 

Thanks for any help. Please let me know if I can provide any further input to
narrow down the root of the problem.

Thanks,
  Holger

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.