Debugging Memory Leaks on GStreamer by analyzing reference counters

From RidgeRun Developer Connection

(Difference between revisions)
Jump to:navigation, search
(Replaced content with 'See GStreamer Debugging#Look for memory leaks')
 
Line 1: Line 1:
-
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).
+
See [[GStreamer Debugging#Look for memory leaks]]
-
 
+
-
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
+
-
 
+
-
<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]]
+

Current revision as of 19:31, 16 October 2012

See GStreamer Debugging#Look for memory leaks

Navigation
Toolbox