Memory leaks in alsa-lib

Memory leaks in alsa-lib

[Måns Rullgård]

Is there a memory leak in alsa-lib?  When playing music with a player
I'm writing (TCVP, http://tcvp.sf.net), the memory usage reported by
top grows for each file I play, but only if I use ALSA for sound
playback.  If I use OSS the memory usage varies around 1.5 MB, but if
I use ALSA, it starts at 1.9 MB (OK, libasound takes some space) and
grows by 30-40 kB for each played file.  Running the whole thing under
valgrind gives me this, which is all alsa-related.  When using OSS,
valgrind reports no leaks.

==3078== 8 bytes in 1 blocks are still reachable in loss record 1 of 20
==3078==    at 0x4002AC23: calloc (../../../valgrind/coregrind/vg_replace_malloc.c:273)
==3078==    by 0x4377069D: snd_config_update_r (conf.c:2953)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)
==3078==    by 0x424D7AC9: t_event (../../../../tcvp/src/tcvp/tcvp.c:581)
==3078==    by 0x402737B3: thread_wrapper (../../../valgrind/coregrind/vg_libpthread.c:667)
==3078==    by 0x40175153: do__quit (../../../valgrind/coregrind/vg_scheduler.c:2146)
==3078== 
==3078== 
==3078== 20 bytes in 1 blocks are still reachable in loss record 6 of 20
==3078==    at 0x4002AC23: calloc (../../../valgrind/coregrind/vg_replace_malloc.c:273)
==3078==    by 0x437706DC: snd_config_update_r (conf.c:2957)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)
==3078==    by 0x424D7AC9: t_event (../../../../tcvp/src/tcvp/tcvp.c:581)
==3078==    by 0x402737B3: thread_wrapper (../../../valgrind/coregrind/vg_libpthread.c:667)
==3078==    by 0x40175153: do__quit (../../../valgrind/coregrind/vg_scheduler.c:2146)
==3078== 
==3078== 
==3078== 48 bytes in 5 blocks are still reachable in loss record 8 of 20
==3078==    at 0x4002A745: malloc (../../../valgrind/coregrind/vg_replace_malloc.c:153)
==3078==    by 0x4376C5E2: get_delimstring (conf.c:769)
==3078==    by 0x4376C6BF: get_string (conf.c:819)
==3078==    by 0x4376C968: parse_value (conf.c:896)
==3078==    by 0x4376CCB7: parse_array_def (conf.c:1029)
==3078==    by 0x4376CE7B: parse_array_defs (conf.c:1051)
==3078==    by 0x4376D16F: parse_def (conf.c:1170)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376CD90: parse_array_def (conf.c:1008)
==3078==    by 0x4376CE7B: parse_array_defs (conf.c:1051)
==3078==    by 0x4376D16F: parse_def (conf.c:1170)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376CD90: parse_array_def (conf.c:1008)
==3078==    by 0x4376CE7B: parse_array_defs (conf.c:1051)
==3078==    by 0x4376D16F: parse_def (conf.c:1170)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376DE43: snd_config_load1 (conf.c:1544)
==3078==    by 0x4376DFDF: snd_config_load (conf.c:1593)
==3078== 
==3078== 
==3078== 173 bytes in 69 blocks are still reachable in loss record 10 of 20
==3078==    at 0x4002A745: malloc (../../../valgrind/coregrind/vg_replace_malloc.c:153)
==3078==    by 0x4030B0CF: __GI___strdup (in /lib/libc-2.3.1.so)
==3078==    by 0x437707DC: snd_config_update_r (conf.c:2979)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)
==3078==    by 0x424D7AC9: t_event (../../../../tcvp/src/tcvp/tcvp.c:581)
==3078==    by 0x402737B3: thread_wrapper (../../../valgrind/coregrind/vg_libpthread.c:667)
==3078==    by 0x40175153: do__quit (../../../valgrind/coregrind/vg_scheduler.c:2146)
==3078== 
==3078== 
==3078== 4820 bytes in 643 blocks are still reachable in loss record 16 of 20
==3078==    at 0x4002A745: malloc (../../../valgrind/coregrind/vg_replace_malloc.c:153)
==3078==    by 0x4376C45B: get_freestring (conf.c:711)
==3078==    by 0x4376C6EE: get_string (conf.c:825)
==3078==    by 0x4376CF1F: parse_def (conf.c:1086)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376DE43: snd_config_load1 (conf.c:1544)
==3078==    by 0x4376DFDF: snd_config_load (conf.c:1593)
==3078==    by 0x437709C5: snd_config_update_r (conf.c:3054)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)
==3078==    by 0x424D7AC9: t_event (../../../../tcvp/src/tcvp/tcvp.c:581)
==3078==    by 0x402737B3: thread_wrapper (../../../valgrind/coregrind/vg_libpthread.c:667)
==3078==    by 0x40175153: do__quit (../../../valgrind/coregrind/vg_scheduler.c:2146)
==3078== 
==3078== 
==3078== 5504 bytes in 172 blocks are still reachable in loss record 17 of 20
==3078==    at 0x4002AC23: calloc (../../../valgrind/coregrind/vg_replace_malloc.c:273)
==3078==    by 0x4376C73A: _snd_config_make (conf.c:836)
==3078==    by 0x4376DD52: snd_config_top (conf.c:1525)
==3078==    by 0x43770927: snd_config_update_r (conf.c:3045)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)
==3078==    by 0x424D7AC9: t_event (../../../../tcvp/src/tcvp/tcvp.c:581)
==3078==    by 0x402737B3: thread_wrapper (../../../valgrind/coregrind/vg_libpthread.c:667)
==3078==    by 0x40175153: do__quit (../../../valgrind/coregrind/vg_scheduler.c:2146)
==3078== 
==3078== 
==3078== 9024 bytes in 282 blocks are possibly lost in loss record 19 of 20
==3078==    at 0x4002AC23: calloc (../../../valgrind/coregrind/vg_replace_malloc.c:273)
==3078==    by 0x4376C73A: _snd_config_make (conf.c:836)
==3078==    by 0x4376C80B: _snd_config_make_add (conf.c:862)
==3078==    by 0x4376CA4D: parse_value (conf.c:956)
==3078==    by 0x4376D0F3: parse_def (conf.c:1184)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376CD90: parse_array_def (conf.c:1008)
==3078==    by 0x4376CE7B: parse_array_defs (conf.c:1051)
==3078==    by 0x4376D16F: parse_def (conf.c:1170)
==3078==    by 0x4376D34D: parse_defs (conf.c:1213)
==3078==    by 0x4376DE43: snd_config_load1 (conf.c:1544)
==3078==    by 0x4376DFDF: snd_config_load (conf.c:1593)
==3078==    by 0x437709C5: snd_config_update_r (conf.c:3054)
==3078==    by 0x43770D67: snd_config_update (conf.c:3095)
==3078==    by 0x43789CC6: snd_pcm_open (pcm.c:1929)
==3078==    by 0x4373C262: alsa_open (../../../../../tcvp/src/output/alsa/alsa.c:355)
==3078==    by 0x424D6E13: new_pipe (../../../../tcvp/src/tcvp/tcvp.c:328)
==3078==    by 0x424D76B9: t_open (../../../../tcvp/src/tcvp/tcvp.c:453)


-- 
Måns Rullgård
mru@users.sf.net


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: Memory leaks in alsa-lib

[Jaroslav Kysela]

On Mon, 25 Aug 2003, [iso-8859-1] Mĺns Rullgĺrd wrote:

> 
> Is there a memory leak in alsa-lib?  When playing music with a player
> I'm writing (TCVP, http://tcvp.sf.net), the memory usage reported by
> top grows for each file I play, but only if I use ALSA for sound
> playback.  If I use OSS the memory usage varies around 1.5 MB, but if
> I use ALSA, it starts at 1.9 MB (OK, libasound takes some space) and
> grows by 30-40 kB for each played file.  Running the whole thing under
> valgrind gives me this, which is all alsa-related.  When using OSS,
> valgrind reports no leaks.

I tested aplay with valgrind and I cannot find any leak (except a few 
allocations probably from glibc). Note that you have to use 
snd_config_update_free_global() after end of the session to free
the configuration cache in alsa-lib. This is described in 
the alsa-lib/MEMORY-LEAK file.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: Memory leaks in alsa-lib

[Måns Rullgård]

Jaroslav Kysela <perex@suse.cz> writes:

>> Is there a memory leak in alsa-lib?  When playing music with a player
>> I'm writing (TCVP, http://tcvp.sf.net), the memory usage reported by
>> top grows for each file I play, but only if I use ALSA for sound
>> playback.  If I use OSS the memory usage varies around 1.5 MB, but if
>> I use ALSA, it starts at 1.9 MB (OK, libasound takes some space) and
>> grows by 30-40 kB for each played file.  Running the whole thing under
>> valgrind gives me this, which is all alsa-related.  When using OSS,
>> valgrind reports no leaks.
>
> I tested aplay with valgrind and I cannot find any leak (except a few 
> allocations probably from glibc). Note that you have to use 
> snd_config_update_free_global() after end of the session to free

OK, so what constitutes a session?  A snd_pcm_open/snd_pcm_close pair?
Won't snd_pcm_open reuse the data from a previous call?

I added that call after my call to snd_pcm_open, and valgrind no
longer reports any leaks, except for a few kilobytes from a flex
scanner (not related to alsa).  Still, the memory used by the player
when running increases with each file.  The virtual size of the player
is rather constant at around 25 MB all the time, while the resident
size is slowly increasing, until it too reaches 25 MB.  Then the
impossible happens:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 7148 mru       11   0 25160  27m 2740 S  0.0 12.4   0:00.08 tcvp              

Now the man page for top tells me that "VIRT = SWAP + RES", so unless
a negative amount has been swapped (what would that mean?), something
strange is going on.  The odd thing is that this happens only when I
use the ALSA output module.  Could it be that alsa-lib triggers some
bug somewhere in top, or in the kernel?  This seems a little unlikely,
though.

In case it matters, I use ALSA OSS emulation when testing OSS sound.

> the configuration cache in alsa-lib. This is described in 
> the alsa-lib/MEMORY-LEAK file.

That file isn't present in the alsa-lib 0.9.6 tarball.  It should be
added the EXTRA_DIST list in Makefile.am.

I ran valgrind on aplay, and it tells me more or less the same as for
my program.  Does aplay not call the above function?  Not that it
needs to, really.


-- 
Måns Rullgård
mru@users.sf.net


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: Memory leaks in alsa-lib

[Jaroslav Kysela]

On Tue, 26 Aug 2003, [iso-8859-1] Mĺns Rullgĺrd wrote:

> Jaroslav Kysela <perex@suse.cz> writes:
> 
> >> Is there a memory leak in alsa-lib?  When playing music with a player
> >> I'm writing (TCVP, http://tcvp.sf.net), the memory usage reported by
> >> top grows for each file I play, but only if I use ALSA for sound
> >> playback.  If I use OSS the memory usage varies around 1.5 MB, but if
> >> I use ALSA, it starts at 1.9 MB (OK, libasound takes some space) and
> >> grows by 30-40 kB for each played file.  Running the whole thing under
> >> valgrind gives me this, which is all alsa-related.  When using OSS,
> >> valgrind reports no leaks.
> >
> > I tested aplay with valgrind and I cannot find any leak (except a few 
> > allocations probably from glibc). Note that you have to use 
> > snd_config_update_free_global() after end of the session to free
> 
> OK, so what constitutes a session?  A snd_pcm_open/snd_pcm_close pair?
> Won't snd_pcm_open reuse the data from a previous call?
> 
> I added that call after my call to snd_pcm_open, and valgrind no
> longer reports any leaks, except for a few kilobytes from a flex
> scanner (not related to alsa).  Still, the memory used by the player
> when running increases with each file.  The virtual size of the player
> is rather constant at around 25 MB all the time, while the resident
> size is slowly increasing, until it too reaches 25 MB.  Then the
> impossible happens:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
>  7148 mru       11   0 25160  27m 2740 S  0.0 12.4   0:00.08 tcvp              
> 
> Now the man page for top tells me that "VIRT = SWAP + RES", so unless
> a negative amount has been swapped (what would that mean?), something
> strange is going on.  The odd thing is that this happens only when I
> use the ALSA output module.  Could it be that alsa-lib triggers some
> bug somewhere in top, or in the kernel?  This seems a little unlikely,
> though.

I will try to investigate this problem.

> In case it matters, I use ALSA OSS emulation when testing OSS sound.
> 
> > the configuration cache in alsa-lib. This is described in 
> > the alsa-lib/MEMORY-LEAK file.
> 
> That file isn't present in the alsa-lib 0.9.6 tarball.  It should be
> added the EXTRA_DIST list in Makefile.am.

Thanks for info. Fixed.

> I ran valgrind on aplay, and it tells me more or less the same as for
> my program.  Does aplay not call the above function?  Not that it
> needs to, really.

I've added the free function to aplay before tests, of course.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0

Re: Memory leaks in alsa-lib

[Måns Rullgård]

Jaroslav Kysela <perex@suse.cz> writes:

>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
>>  7148 mru       11   0 25160  27m 2740 S  0.0 12.4   0:00.08 tcvp     
>> 
>> Now the man page for top tells me that "VIRT = SWAP + RES", so unless
>> a negative amount has been swapped (what would that mean?), something
>> strange is going on.  The odd thing is that this happens only when I
>> use the ALSA output module.  Could it be that alsa-lib triggers some
>> bug somewhere in top, or in the kernel?  This seems a little unlikely,
>> though.
>
> I will try to investigate this problem.

I seems to be a kernel problem.  See my recent post to linux-kernel on
the subject for more details.

-- 
Måns Rullgård
mru@users.sf.net


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0