What is the pipeline that shows these leaks ?
The code which that trace refers to seems OK, and double checking with audiotestsrc num-buffers=17 ! audioconvert ! adpcmenc ! adpcmdec ! fakesink does not show leaks.

here is the pipeline:

gst-launch -v -e souphttpsrc do-timestamp=true is-live=true timeout=5 location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! asfdemux name=demux demux.video_00 ! queue ! jpegparse ! jpegdec ! clockoverlay text=overlay valignment=top halignment=right xpad=5 ypad=5 time-format=\"%d/%m/%Y %H:%M:%S\" font-desc=\"Monospace\" shaded-background=true ! xvimagesink demux.audio_00 ! queue ! adpcmdec ! pulsesink

Please use G_SLICE=always-malloc when running gstreamer under valgrind.  If there's a slice leak, it could be due to something completely unrelated.

I generally use this:

alias vg_memcheck='G_SLICE=always-malloc G_DEBUG=gc-friendly GLIBCPP_FORCE_NEW=1 GLIBCXX_FORCE_NEW=1 valgrind --tool=memcheck --leak-check=full --leak-resolution=high --trace-children=yes --num-callers=20 -v --suppressions=/home/nicola/gst.supp'

Please provide a test file if it still happens.
I see no leak with some sample-in-ASF found off the mplayer website.

Vincent, I have no more that camera, I can try to gain remote access but not before the beginning of the next week

Hi Vincent,

I did some more tests, the leak seems related to pulsesink and not adpcmdec, I can easily reproduce the reported definitely lost with this pipeline:

gst-launch -v -e souphttpsrc is-live=true timeout=5 location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! asfdemux name=demux demux.audio_00 ! queue ! adpcmdec ! pulsesink

but it doesn't happen using this (I tested for about 1 hour):

gst-launch -v -e souphttpsrc is-live=true timeout=5 location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! asfdemux name=demux demux.audio_00 ! queue ! adpcmdec ! fakesink

pulsesink show several leaks (some related to gstreamer and some to the pulseaudio library) you can easily reproduce with pulsesrc ! pulsesink, if you want I can report them in a separate bug,

thanks
Nicola

OK, I was using pulsesink too, but my ADPCM in ASF is short, so maybe it just doesn't leak buffers that often. Thanks for retesting.

Vincent, please try this:

gst-launch pulsesrc ! pulsesink

on my system I have these valgrind report (only a leak seems caused by gstreamer code):

==13086== 
==13086== HEAP SUMMARY:
==13086==     in use at exit: 568,849 bytes in 2,496 blocks
==13086==   total heap usage: 66,972 allocs, 64,476 frees, 27,813,295 bytes allocated
==13086== 
==13086== Searching for pointers to 2,496 not-freed blocks
==13086== Checked 9,222,488 bytes
==13086== 
==13086== Thread 1:
==13086== 124 bytes in 1 blocks are definitely lost in loss record 1,827 of 1,968
==13086==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==13086==    by 0xA317564: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA31762A: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA3171CA: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0x9EA90ED: pa_client_conf_from_x11 (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9A2983E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x8F41544: gst_pulsemixer_ctrl_new (pulsemixerctrl.c:270)
==13086==    by 0x8F51B95: gst_pulsesrc_change_state (pulsesrc.c:1687)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x4E5EEA9: gst_bin_change_state_func (gstbin.c:2209)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x403AF1: main (gst-launch.c:1104)
==13086== 
==13086== 124 bytes in 1 blocks are definitely lost in loss record 1,828 of 1,968
==13086==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==13086==    by 0xA317564: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA31762A: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA3171CA: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0x9EA90ED: pa_client_conf_from_x11 (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9A2983E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x8F4643F: gst_pulseringbuffer_open_device (pulsesink.c:495)
==13086==    by 0x9166B63: gst_ring_buffer_open_device (gstringbuffer.c:662)
==13086==    by 0x917D8A4: gst_base_audio_sink_change_state (gstbaseaudiosink.c:2146)
==13086==    by 0x8F4A370: gst_pulsesink_change_state (pulsesink.c:2977)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x4E5EEA9: gst_bin_change_state_func (gstbin.c:2209)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x403AF1: main (gst-launch.c:1104)
==13086== 
==13086== 124 bytes in 1 blocks are definitely lost in loss record 1,829 of 1,968
==13086==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==13086==    by 0xA317564: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA31762A: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0xA3171CA: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==13086==    by 0x9EA90ED: pa_client_conf_from_x11 (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9A2983E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x8F4EF35: gst_pulsesrc_open (pulsesrc.c:1020)
==13086==    by 0x9166B63: gst_ring_buffer_open_device (gstringbuffer.c:662)
==13086==    by 0x918071B: gst_base_audio_src_change_state (gstbaseaudiosrc.c:1088)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x4E5EEA9: gst_bin_change_state_func (gstbin.c:2209)
==13086==    by 0x4E71E9B: gst_element_change_state (gstelement.c:2761)
==13086==    by 0x4E727F1: gst_element_set_state_func (gstelement.c:2717)
==13086==    by 0x403AF1: main (gst-launch.c:1104)
==13086== 
==13086== 36,208 (1,824 direct, 34,384 indirect) bytes in 12 blocks are definitely lost in loss record 1,966 of 1,968
==13086==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==13086==    by 0x55BB682: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0)
==13086==    by 0x55D0406: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0)
==13086==    by 0x55D06E5: g_slice_alloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0)
==13086==    by 0x514BEF8: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.0)
==13086==    by 0x4E84541: gst_mini_object_new (gstminiobject.c:217)
==13086==    by 0x4E5FDD0: gst_buffer_new (gstbuffer.c:503)
==13086==    by 0x4E5FE3C: gst_buffer_new_and_alloc (gstbuffer.c:533)
==13086==    by 0x917E69C: gst_base_audio_src_create (gstbaseaudiosrc.c:808)
==13086==    by 0x97EF107: gst_base_src_get_range (gstbasesrc.c:2188)
==13086==    by 0x97F03C2: gst_base_src_loop (gstbasesrc.c:2445)
==13086==    by 0x4EB6683: gst_task_func (gsttask.c:327)
==13086==    by 0x55DC7D7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0)
==13086==    by 0x55DA2B5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.0)
==13086==    by 0x586DEFB: start_thread (pthread_create.c:304)
==13086==    by 0x5B6489C: clone (clone.S:112)
==13086== 
==13086== LEAK SUMMARY:
==13086==    definitely lost: 2,196 bytes in 15 blocks
==13086==    indirectly lost: 34,624 bytes in 28 blocks
==13086==      possibly lost: 0 bytes in 0 blocks
==13086==    still reachable: 42,968 bytes in 555 blocks
==13086==         suppressed: 489,061 bytes in 1,898 blocks

there is also a conditional jump or move and this error that seems specific to pulseaudio:

==13086== 1 errors in context 1 of 6:
==13086== Thread 2:
==13086== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==13086==    at 0x587567C: send (send.c:33)
==13086==    by 0x9E83144: pa_write (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9E8B68E: pa_iochannel_write (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9E9CD68: ??? (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x9A3D70D: pa_mainloop_dispatch (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x9A3DAD4: pa_mainloop_iterate (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x9A3DB7F: pa_mainloop_run (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x9A4BFEE: ??? (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==13086==    by 0x9EAAC77: ??? (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==13086==    by 0x586DEFB: start_thread (pthread_create.c:304)
==13086==    by 0x5B6489C: clone (clone.S:112)

Interestingly, I do see those with pulsesrc ! pulsesink. Trying again with asfdemux ! adpcmdec ! pulsesink, they still do not appear. Maybe buffer timestamp related, then, if pulsesink keeps buffers around depending on overlap/gaps.

Yes it is something weired, I can easily reproduce the original bug report using:

gst-launch -v -e souphttpsrc is-live=true timeout=5
location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! asfdemux name=demux demux.audio_00 ! queue ! adpcmdec ! pulsesink

but if I use:

gst-launch -v -e souphttpsrc is-live=true timeout=5
location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! asfdemux name=demux demux.audio_00 ! gdppay ! filesink ..

or

gst-launch -v -e souphttpsrc is-live=true timeout=5
location="http://192.168.10.103/videostream.asf?user=admin&pwd=&resolution=8&rate=3" ! filesink ..

and then I use pulsesink, in the pipeline to play the recorded file, valgrind show no leak

Fixed. Thanks for investigating.

commit 12be1e6fc56b91049d6eddda75362696fddb0afe
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Tue Dec 13 12:55:45 2011 +0000

    baseaudiosink: fix late buffer leak

I can confirm that the commit fix my original report too,

thanks
Nicola