Gstreamer & GLib memory management/profiling

[Sergei Vorobyov]

So it's useless for programs that run forever. Besides, it's obvious that
the memory leaks problem is algorithmically unsolvable, in principle. E.g.,
if you stop your program and it reports "leak", you can never be sure, it
may be freed some time later; you can never dis/prove if a memory block is
saved, say in a list, or lost/leaked, etc, etc).

Consequently, Valgrind is a "mission impossible" project, no mater how you
like it.

On Fri, Oct 31, 2014 at 10:06 PM, Tim Müller <tim at centricular.com> wrote:

> On Fri, 2014-10-31 at 21:51 +0100, Sergei Vorobyov wrote:
>
> > Since GLib's memory profiling fails and there was a lot of Valgrind
> > propaganda around, I gave it a try with: (snip)
>
> > Therefore: I decided to perform an easy experiment with an obvious
> > test leak:
> >
> >
> >     gchar *leak;
> >     for (gint i = 1; ; i++) {
> >         // my main loop code here
> >         leak = g_strdup_printf ("iteration %d", i);
> >         g_printerr ("!!! LEAK: %s\n", leak);
> >     }
> >
> >
> > Obviously, Valgrind does not catch this trivial case (leak is never
> > freed and non-recoverable):
> >
> >
> > fl at nuc5:~/bin$ valgrind --leak-check=yes --leak-check=full
> > --show-leak-kinds=all ./mp-v01.020 >../var/z3.txt
> > ==8677== Memcheck, a memory error detector
> > ==8677== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
> > al.
> > ==8677== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for
> > copyright info
> > ==8677== Command: ./mp-v01.020
> > ==8677==
> > !!! LEAK: iteration 1
> > !!! LEAK: iteration 2
> > !!! LEAK: iteration 3
> > !!! LEAK: iteration 4
> > !!! LEAK: iteration 5
> > !!! LEAK: iteration 6
> > !!! LEAK: iteration 7
> > !!! LEAK: iteration 8
> > ...
> >
> >
> > I don't buy it...
>
> Leaks will only shown when the program exits or you terminate it with
> Control-C. And it will generally show this kind of leak just fine:
>
> !!! LEAK: iteration 9682
> !!! LEAK: iteration 9683
> ^C==26170==
> ==26170== HEAP SUMMARY:
> ==26170==     in use at exit: 144,266 bytes in 9,690 blocks
> ==26170==   total heap usage: 77,478 allocs, 67,788 frees, 321,951,609
> bytes allocated
> ==26170==
> ==26170== 144,138 bytes in 9,683 blocks are definitely lost in loss
> record 8 of 8
> ==26170==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
> ==26170==    by 0x5239BAF: __vasprintf_chk (vasprintf_chk.c:80)
> ==26170==    by 0x4EC247B: g_vasprintf
> (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
> ==26170==    by 0x4E9D30C: g_strdup_vprintf
> (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
> ==26170==    by 0x4E9D3C8: g_strdup_printf
> (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
> ==26170==    by 0x4006EF: main (in /home/tpm/leak)
> ==26170==
> ==26170== LEAK SUMMARY:
> ==26170==    definitely lost: 144,138 bytes in 9,683 blocks
> ==26170==    indirectly lost: 0 bytes in 0 blocks
> ==26170==      possibly lost: 0 bytes in 0 blocks
> ==26170==    still reachable: 128 bytes in 7 blocks
> ==26170==         suppressed: 0 bytes in 0 blocks
> ==26170== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==26170== To see them, rerun with: --leak-check=full
> --show-leak-kinds=all
> ==26170==
> ==26170== For counts of detected and suppressed errors, rerun with: -v
> ==26170== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>
>  Cheers
>   -Tim
>
> --
> Tim Müller, 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/20141031/3a864185/attachment.html>