Huge memory leak sometime after starting a pipeline

[Sergei Vorobyov]

Sorry to say but the universal (on this list) recipe to use valgrind is
useless, like a hammer to drive screws.

Point is, to see "leaks", you need to stop your application, in which case
GStreamer produces thousands (miles) of messages of the kind:

==8263== 2,360 bytes in 59 blocks are possibly lost in loss record 5,656 of
5,790
==8263==    at 0x4C2ABA0: malloc (vg_replace_malloc.c:296)
==8263==    by 0x56127C9: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
==8263==    by 0x562970F: g_slice_alloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
==8263==    by 0x537C7C9: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==8263==    by 0x537C885: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==8263==    by 0x539CE7F: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==8263==    by 0x539EDCD: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==8263==    by 0x53A352F: g_type_add_interface_static (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==8263==    by 0x170E7083: gst_ffmpegmux_register (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so)
==8263==    by 0x170C8187: plugin_init (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so)
==8263==    by 0x50D2686: gst_plugin_register_func (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.403.0)
==8263==    by 0x50D454C: gst_plugin_load_file (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.403.0)
==8263==
==8263== 5,168 (512 direct, 4,656 indirect) bytes in 1 blocks are
definitely lost in loss record 5,719 of 5,790

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

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?

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.

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.





On Thu, Nov 6, 2014 at 10:28 AM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Mi, 2014-11-05 at 21:26 +0000, Chris Tapp wrote:
> > My application uses gst_parse_launch to create a pipleline of the form:
> >
> >    playbin av-offset=-50000000 buffer-size=0 buffer-duration=0
> name="name" uri=http://dvb:4242/bysid/4352 audio-sink="alsasink"
> video-sink="videoconvert ! videoscale !
> video/x-raw,format=(string)RGBA,width=300,height=200 ! fakesink sync=true
> >
> > It then uses the pipeline "sample" property to read frames as required.
> >
> > 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).
> >
> > 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:
> >
> >    Timestamp
> >    0:36:45   50 more _init than _free
> >    0:52:43   61 more _init than _free
> >    0:59:45   55 more _init than _free
> >    1:09:00   76796  more _init than _free
> >
> > How should I go about trying to work out what's going on?
>
> If it is a leak, you can try with valgrind's memchecker... if it's
> memory accumulating somewhere but not being lost you can check with
> valgrind's massif tool where a lot of memory is allocated.
>
> Alternatively the TRACE (7) debug level will give you details about when
> and where every memory and surrounding buffer is reffed, unreffed and
> also where it was last seen.
>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141106/65d73797/attachment-0001.html>