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).

An easy way to debug the memory leak of a GStreamer program that is running is by looking at the reference counters. Memory leaks on gstreamer happened because reference counters on one or more objects never go back to zero.

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.