* Memory leaks in alsa-lib @ 2003-08-25 16:07 Måns Rullgård 2003-08-26 10:07 ` Jaroslav Kysela 0 siblings, 1 reply; 5+ messages in thread From: Måns Rullgård @ 2003-08-25 16:07 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in alsa-lib 2003-08-25 16:07 Memory leaks in alsa-lib Måns Rullgård @ 2003-08-26 10:07 ` Jaroslav Kysela 2003-08-26 11:53 ` Måns Rullgård 0 siblings, 1 reply; 5+ messages in thread From: Jaroslav Kysela @ 2003-08-26 10:07 UTC (permalink / raw) To: Måns Rullgård; +Cc: alsa-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in alsa-lib 2003-08-26 10:07 ` Jaroslav Kysela @ 2003-08-26 11:53 ` Måns Rullgård 2003-08-26 12:33 ` Jaroslav Kysela 0 siblings, 1 reply; 5+ messages in thread From: Måns Rullgård @ 2003-08-26 11:53 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: alsa-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in alsa-lib 2003-08-26 11:53 ` Måns Rullgård @ 2003-08-26 12:33 ` Jaroslav Kysela 2003-08-26 13:14 ` Måns Rullgård 0 siblings, 1 reply; 5+ messages in thread From: Jaroslav Kysela @ 2003-08-26 12:33 UTC (permalink / raw) To: Måns Rullgård; +Cc: alsa-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Memory leaks in alsa-lib 2003-08-26 12:33 ` Jaroslav Kysela @ 2003-08-26 13:14 ` Måns Rullgård 0 siblings, 0 replies; 5+ messages in thread From: Måns Rullgård @ 2003-08-26 13:14 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: alsa-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-08-26 13:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-08-25 16:07 Memory leaks in alsa-lib Måns Rullgård 2003-08-26 10:07 ` Jaroslav Kysela 2003-08-26 11:53 ` Måns Rullgård 2003-08-26 12:33 ` Jaroslav Kysela 2003-08-26 13:14 ` Måns Rullgård
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.