Debugging Memory Leaks on GStreamer by analyzing reference counters: Difference between revisions
No edit summary |
mNo edit summary |
||
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). | 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]] | [[Category:GStreamer]] [[Category:Whitepaper]] |
Revision as of 17:18, 26 August 2010
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
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.