Memory Leak in Sample Gstreamer Application

[Tim-Philipp Müller]

On Mon, 2013-01-07 at 03:23 -0800, Aditya wrote:

Hi,

> I am finding memory Leaks in the Sample Application given in the Gstreamer
> Manual.
> I am using 0.10.36 Gstreamer core and gst-plugins-base package.

In case you are not aware, GStreamer 0.10 is not maintained any longer,
and these releases are almost a year old. If possible at all I would
recommend you use GStreamer 1.0.


> This is the valgrind command I have used
> 
> export G_SLICE=always-malloc
> export G_DEBUG=gc-friendly
> 
> valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes
> --time-stamp=yes --undef-value-errors=no --malloc-fill=0xc --free-fill=0xd
> --freelist-vol=100000000 --trace-children=yes --num-callers=50
> --suppressions=gst.supp --log-file=valgrind_gst ./gstapp nancy.mp4
> 
> I am seeing lots of possibly lost memory in the gst_element_factory_make(..)
> 
> ==3883== 9,936 bytes in 207 blocks are possibly lost in loss record 2,501 of
> 2,524
> ==3883==    at 0x4A0620D: realloc (vg_replace_malloc.c:476)
> ==3883==    by 0x55B1548: g_realloc (gmem.c:233)
> ==3883==    by 0x4F1F7FF: g_type_set_qdata (gtype.c:3688)
> ==3883==    by 0x4C53FD0: gst_element_register (gstelementfactory.c:236)
> ==3883==    by 0xAECFFD8: gst_ffmpegdec_register (gstffmpegdec.c:2964)
> ==3883==    by 0xAEC29AC: plugin_init (gstffmpeg.c:142)
> ==3883==    by 0x4C73955: gst_plugin_register_func (gstplugin.c:557)
> ==3883==    by 0x4C74831: gst_plugin_load_file (gstplugin.c:843)
> ==3883==    by 0x4C75399: gst_plugin_load_by_name (gstplugin.c:1297)
> ==3883==    by 0x4C769C1: gst_plugin_feature_load (gstpluginfeature.c:112)
> ==3883==    by 0x4C52D3B: gst_element_factory_create
> (gstelementfactory.c:362)
> ==3883==    by 0x4C53D7B: gst_element_factory_make (gstelementfactory.c:455)
> 
> I had tried running the app in a loop and saw the Resident memory on the
> system increasing.
> I have referred to the previous posts but could not figure out why there is
> lots of possibly lost memory.
> 
> Am I missing something ?

As a first step, it's usually best to ignore all 'possibly lost' and
concentrate on the 'definitely lost'. There are a fair number of global
one-time allocs going on in GLib, GObject and GStreamer that will show
up as 'possibly lost'. This is one of those that are safe to ignore.

There are also some gst.supp valgrind suppression files in the GStreamer
common module and in the various gst-plugins-* tests/check/ folders, but
they don't cover everything of course.

You could also try valgrind's "massif" tool to see where the main memory
allocations are made from. That might help track down
constantly-increasing-but-not-actually-leaked memory. Run ms_print on
the massif.out.$PID file you get for a quick overview.

Cheers
 -Tim