Gstreamer & GLib memory management/profiling

Fri Oct 31 13:51:13 PDT 2014

Since GLib's memory profiling fails and there was a lot of Valgrind
propaganda around, I gave it a try with:

valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all
./mp-v01.020 >../var/z3.txt

to see just stderr where Valgrind prints its messages prefixed with ==.

I was very proud to see that my program is completely (except for
vaapisink) memcheck-clean (although, frankly, I know it leaks memory
somewhere: it goes from 1% to 50% of 16GB of system memory in 3 hours;
sure, I blame the graphics driver and libraries).

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==

videosink=vaapisink
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_35
==8677== Thread 5 play ads:
==8677== Syscall param ioctl(generic) points to uninitialised byte(s)
==8677==    at 0x5DCDE77: ioctl (syscall-template.S:81)
==8677==    by 0x18C2F3A3: drmIoctl (in
/usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==8677==    by 0x18C316EE: drmCommandWriteRead (in
/usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==8677==    by 0x1EB9EE59: intel_driver_init (in
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
==8677==    by 0x1EB82D67: __vaDriverInit_0_35 (in
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so)
==8677==    by 0x1670C207: ??? (in
/usr/lib/x86_64-linux-gnu/libva.so.1.3501.0)
==8677==    by 0x1670CF0A: vaInitialize (in
/usr/lib/x86_64-linux-gnu/libva.so.1.3501.0)
==8677==    by 0x19054B42: gst_vaapi_display_new (in
/usr/lib/x86_64-linux-gnu/libgstvaapi-1.2.so.0.0.0)
==8677==    by 0x11344B21: ??? (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so)
==8677==    by 0x11348895: ??? (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so)
==8677==    by 0x1134A798: ??? (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so)
==8677==    by 0x6E9FCD3: gst_base_sink_query_caps (in
/usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.204.0)
==8677==  Address 0xafaf764 is on thread 5's stack
==8677==
libva info: va_openDriver() returns 0
==8677== Conditional jump or move depends on uninitialised value(s)
==8677==    at 0x19055A0E: gst_vaapi_display_get_render_mode (in
/usr/lib/x86_64-linux-gnu/libgstvaapi-1.2.so.0.0.0)
==8677==    by 0x1134893E: ??? (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so)
==8677==    by 0x1134A798: ??? (in
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so)
==8677==    by 0x6E9FCD3: gst_base_sink_query_caps (in
/usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.204.0)
==8677==    by 0x6E9FDB0: gst_base_sink_default_query (in
/usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.204.0)
==8677==    by 0x50C34E9: gst_pad_query (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.204.0)
==8677==    by 0x50F2913: gst_pad_query_caps (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.204.0)
==8677==    by 0x50F34D4: gst_element_get_compatible_pad (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.204.0)
==8677==    by 0x50F409D: gst_element_link_pads_full (in
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.204.0)
==8677==    by 0x40B8EE: build_pipeline (mp.c:301)
==8677==    by 0x40932C: schedules_play_cycle (mp-main.c:387)
==8677==    by 0x561FF04: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==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...

On Fri, Oct 31, 2014 at 5:04 PM, Nicolas Dufresne <
nicolas.dufresne at collabora.com> wrote:

>
> Le 2014-10-31 11:42, Sergei Vorobyov a écrit :
>
>> I "forgot" the line
>>
>> extern GMemVTable *glib_mem_profiler_table;
>>
>> before int main ....
>>
>> (by a nasty habit of C-x C-s, which saves in emacs but kills the line and
>> saves in Netbeans)
>>
>> But it *does not change anything*, since it is already defined somewhere
>> in GLib headers.
>>
>
> It looks like GLib profiler is reading before each allocation (assuming
> it's own padded allocator was used), but some allocation seems to be from
> calloc instead of the profile alloc. Valgrind bad read are all targetting
> stuff within _dl_init (dl-init.c:34), so basically, stuff that runs before
> your main. A talk with the authors on how dynamic library with init
> function are supposed to work would be nice.
>
> Nicolas
>
>
> _______________________________________________
> 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/fe6cdad5/attachment.html>