View source for Debugging Memory Leaks on GStreamer by analyzing reference counters

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

== GStreamer Debug Variables ==

You can list the GStreamer debug variable using

<pre>
gst-launch --gst-debug-help
</pre>

== GStreamer <tt>GST_REFCOUNTING</tt> Debug Variable ==

One of the debug variables is <tt>GST_REFCOUNTING</tt>.

[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 <tt>GST_REFCOUNTING</tt>  ==

<pre>
--gst-debug=GST_REFCOUNTING:5
</pre>

== 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:

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

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.



[[Category:GStreamer]] [[Category:Whitepaper]]