Debugging Memory Leaks on GStreamer by analyzing reference counters

From RidgeRun Developer Connection

Revision as of 17:18, 26 August 2010 by Tfischer (Talk | contribs)
Jump to:navigation, search

Looking for memory leaks in programs is a very challenging problem. This is even more true for embedded systems, since some of the best tools for this aren't always available (like valgrind), or are difficult to use on this environment (like compile-time hacks, since you depend on other libraries that you may not be able to recompile).


so, this is the easy way to debug the memory leak of a program that is running

looking at the reference counters

memory leaks on gstreamer happened because rought reference counters
if you run "gst-launch --gst-debug-help"

you will see a list of debug variables that can be used

Contents

GStreamer Debug Variables

You can list the GStreamer debug variable using

gst-launch --gst-debug-help

GStreamer GST_REFCOUNTING Debug Variable

One of the debug variables is GST_REFCOUNTING.

[09:40:37] … one of them is GST_REFCOUNTING [09:41:37] … with that, you can get a log of all the refcount changes that happened inside a gst application

Setting GST_REFCOUNTING

--gst-debug=GST_REFCOUNTING:5

Filtering debug output

Here are several examples on how to filter the debug output.

You can see which objects disappear, meaning their reference count reaches zero:

gst-launch videotestsrc num-buffers=3 ! fakesink --gst-debug=GST_REFCOUNTING:5 2> log.txt
grep "\->0" log.txt  | cut -d' ' -f 19

On useful applications there are always some objects that aren't freed until the program exists. With a simple gst-hello example all the objects are always freed. If you set the pipe to run, lets say 13 times, and in the log you see one object that wasn't freed and the count reached 13 or more, then you have a suspicious object or if you see that the number of non-freed objects increase as you increase the number of runs, then you have an indication of a problem.

Navigation
Toolbox