<div dir="ltr"><div>Sorry to say but the universal (on this list) recipe to use valgrind is useless, like a hammer to drive screws.</div><div><br></div><div>Point is, to see "leaks", you need to stop your application, in which case GStreamer produces thousands (miles) of messages of the kind:</div><div><br></div><div>==8263== 2,360 bytes in 59 blocks are possibly lost in loss record 5,656 of 5,790</div><div>==8263==    at 0x4C2ABA0: malloc (vg_replace_malloc.c:296)</div><div>==8263==    by 0x56127C9: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)</div><div>==8263==    by 0x562970F: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)</div><div>==8263==    by 0x537C7C9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)</div><div>==8263==    by 0x537C885: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)</div><div>==8263==    by 0x539CE7F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)</div><div>==8263==    by 0x539EDCD: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)</div><div>==8263==    by 0x53A352F: g_type_add_interface_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)</div><div>==8263==    by 0x170E7083: gst_ffmpegmux_register (in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so)</div><div>==8263==    by 0x170C8187: plugin_init (in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so)</div><div>==8263==    by 0x50D2686: gst_plugin_register_func (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.403.0)</div><div>==8263==    by 0x50D454C: gst_plugin_load_file (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.403.0)</div><div>==8263== </div><div>==8263== 5,168 (512 direct, 4,656 indirect) bytes in 1 blocks are definitely lost in loss record 5,719 of 5,790</div><div><br></div><div>even though you make a clean exit with _unrefs of all kinds and gst_deinit (), and the application does not leak at all (if you don't stop it and run indefinitely).</div><div><br></div><div>Sure (by the end of the day) you can suppress any kind of messages you want to ignore, but this hardly approaches you to the solution of the problem. Should you take the above message seriously or ignore? Can you ask GStreamer developers "take seriously or ignore?" about each of 100.000 such messages?</div><div><br></div><div>I observed (without valgrind) a curious thing: the same application leaks as hell on Intel's HD4400 IGP (NUC) with Intel's driver, but does not leak at all on AMD Radeon, nor on NVidia. As I said, in all three cases valgrind uselessly reports miles of possibly and definitely lost blocks, which makes all three different cases completely indistinguishable.</div><div><br></div><div>Check if you are using Intel's graphics HW. Maybe this is the reason. Despite the developers claim that GStreamer runs equally good on any hardware.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 10:28 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mi, 2014-11-05 at 21:26 +0000, Chris Tapp wrote:<br>
> My application uses gst_parse_launch to create a pipleline of the form:<br>
><br>
>    playbin av-offset=-50000000 buffer-size=0 buffer-duration=0 name="name" uri=<a href="http://dvb:4242/bysid/4352" target="_blank">http://dvb:4242/bysid/4352</a> audio-sink="alsasink" video-sink="videoconvert ! videoscale ! video/x-raw,format=(string)RGBA,width=300,height=200 ! fakesink sync=true<br>
><br>
> It then uses the pipeline "sample" property to read frames as required.<br>
><br>
> This generally works fine, but after some time (from a few minutes to many hours) a memory leak develops which leads to the program being terminated. The application itself processes all samples the same (basically copies the image to a gl texture without holding any references and no control-flow variations).<br>
><br>
> Examining the log created with GST_DEBUG=GST_MEMORY:5 for a particular run shows that the number of calls to _gst_memory_init and _gst_memory_free are basically the same when the application works normally, but there is a significant deficit of calls to _gst_memory_free when it goes wrong:<br>
><br>
>    Timestamp<br>
>    0:36:45   50 more _init than _free<br>
>    0:52:43   61 more _init than _free<br>
>    0:59:45   55 more _init than _free<br>
>    1:09:00   76796  more _init than _free<br>
><br>
> How should I go about trying to work out what's going on?<br>
<br>
</span>If it is a leak, you can try with valgrind's memchecker... if it's<br>
memory accumulating somewhere but not being lost you can check with<br>
valgrind's massif tool where a lot of memory is allocated.<br>
<br>
Alternatively the TRACE (7) debug level will give you details about when<br>
and where every memory and surrounding buffer is reffed, unreffed and<br>
also where it was last seen.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br>
</font></span><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>