gstreamer and valgrind

Wed Aug 20 06:51:56 PDT 2014

[...]

> >
> > GStreamer now works differently
> 
> Note that the message says that it *might* now take different code
> paths
> to ease debugging. As far as I know, it doesn't actually do that in
> practice, besides printing that info text.
> 
> >  and I get leaks quite rarely.
> 
> Are you sure about that? Perhaps it just leaks slower because it runs
> slower?

Yes it runs and leaks much slower, but it has been a bit more difficult to trigger the leak. The way to trigger it is quite strange (explained below).

The setup is:

1. First computer: ffmpeg streaming mpegts to udp://secondComputer:5555 - ffmpeg grabs input of avermedia grabbing card.
2. On the second one the (simplified) pipeline is:
udpsrc -> queue -> decodebin -> [...] -> avenc_flv -> flvmux -> rtmpsink

I've run similar pipelines with different sources (left of [...]) without noticing any serious leakage. (shmsink, decklinksrc, filesrc).

To trigger the leak:
1. Start the pipeline with the stream content being video of static image (No signal panel from avermedia card on the other computer)
2. Start video input on the avermedia, so it's no longer static image.
3. After some time turn off the signal, video goes back to static image.
4. Huge leaking starts now.

It's a way that triggers the leak 100% of the time. If I stop at point 1 or 2 there seems to be no significant leak during 10min test period - leaking starts immediately after switching the signal off.

I suppose this switching of signal on the first computer should have no influence on GStreamer, ffmpeg is streaming all the time, just different content - do you have any idea why this might happen? I'm using GStreamer 1.2.4, were there any significant leak fixes in the meantime?

I will try to prepare a test case with clean GStreamer, without our application. In the meantime this is the bottom of Valgrind log without G_SLICE=always-malloc, below that one is another one, with G_SLICE set. Application was stopped with ctrl-c, unfortunately there is no easy way to terminate it normally.

==8282== 174,974,310 bytes in 90 blocks are possibly lost in loss record 9,438 of 9,440
==8282==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8282==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==8282==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==8282==    by 0x289F275C: video_buffer_pool_alloc (gstvideopool.c:195)
==8282==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==8282==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==8282==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==8282==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==8282==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==8282==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==8282==
==8282== 221,634,126 bytes in 114 blocks are indirectly lost in loss record 9,439 of 9,440
==8282==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8282==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==8282==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==8282==    by 0x289F275C: video_buffer_pool_alloc (gstvideopool.c:195)
==8282==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==8282==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==8282==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==8282==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==8282==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==8282==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==8282==
==8282== 743,315,903 bytes in 377 blocks are still reachable in loss record 9,440 of 9,440
==8282==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8282==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==8282==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==8282==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==8282==    by 0x289F275C: video_buffer_pool_alloc (gstvideopool.c:195)
==8282==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==8282==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==8282==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==8282==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==8282==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==8282==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==8282==
==8282== LEAK SUMMARY:
==8282==    definitely lost: 77,952 bytes in 274 blocks
==8282==    indirectly lost: 223,170,538 bytes in 879 blocks
==8282==      possibly lost: 175,129,187 bytes in 2,281 blocks
==8282==    still reachable: 772,523,997 bytes in 102,118 blocks
==8282==         suppressed: 0 bytes in 0 blocks
==8282==
==8282== For counts of detected and suppressed errors, rerun with: -v
==8282== Use --track-origins=yes to see where uninitialised values come from
==8282== ERROR SUMMARY: 915 errors from 871 contexts (suppressed: 0 from 0)
(END)

Here a different run with G_SLICE:
==13331== 190,527,582 bytes in 98 blocks are possibly lost in loss record 9,466 of 9,468
==13331==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13331==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==13331==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==13331==    by 0x287DD75C: video_buffer_pool_alloc (gstvideopool.c:195)
==13331==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==13331==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==13331==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==13331==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==13331==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==13331==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==13331==
==13331== 217,745,808 bytes in 112 blocks are indirectly lost in loss record 9,467 of 9,468
==13331==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13331==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==13331==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==13331==    by 0x287DD75C: video_buffer_pool_alloc (gstvideopool.c:195)
==13331==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==13331==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==13331==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==13331==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==13331==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==13331==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==13331==
==13331== 799,696,514 bytes in 406 blocks are still reachable in loss record 9,468 of 9,468
==13331==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13331==    by 0x4E85610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x4E9B22D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==13331==    by 0x63B87CC: _sysmem_new_block (gstallocator.c:415)
==13331==    by 0x63C2471: gst_buffer_new_allocate (gstbuffer.c:668)
==13331==    by 0x287DD75C: video_buffer_pool_alloc (gstvideopool.c:195)
==13331==    by 0x63C5353: do_alloc_buffer.constprop.2 (gstbufferpool.c:272)
==13331==    by 0x63C56F5: default_acquire_buffer (gstbufferpool.c:995)
==13331==    by 0x63C6A01: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099)
==13331==    by 0xB8C663A: default_prepare_output_buffer (gstbasetransform.c:1577)
==13331==    by 0xB8C83BA: gst_base_transform_handle_buffer (gstbasetransform.c:2065)
==13331==    by 0xB8C8D00: gst_base_transform_chain (gstbasetransform.c:2201)
==13331==
==13331== LEAK SUMMARY:
==13331==    definitely lost: 78,872 bytes in 277 blocks
==13331==    indirectly lost: 221,424,134 bytes in 906 blocks
==13331==      possibly lost: 190,732,025 bytes in 2,769 blocks
==13331==    still reachable: 841,250,822 bytes in 102,333 blocks
==13331==         suppressed: 0 bytes in 0 blocks
==13331==
==13331== For counts of detected and suppressed errors, rerun with: -v
==13331== Use --track-origins=yes to see where uninitialised values come from
==13331== ERROR SUMMARY: 1098 errors from 874 contexts (suppressed: 0 from 0)

-- 
Best regards,
Krzysztof Borowczyk