alsa - mem leak?

Question

I\'ve been chasing a memory leak (reported by \'valgrind --leak-check=yes\') and it appears to be coming from ALSA. This code has been in the free world for some time so I\'

Answer 1

The biggest reported leak is that the global configuration is cached for next usage.

If you do not want this feature, simply call snd_config_update_free_global() after all snd_*_open*() calls.

This function will free the cache." <---- Valgrind still detects leaks.

This can be fixed if you call snd_config_update_free_global() after snd_pcm_close(handle);

Answer 2

http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=MEMORY-LEAK;hb=HEAD says:

                          Memory leaks - really?
                          ----------------------

Note that some developers are thinking that the ALSA library has some memory leaks. Sure, it can be truth, but before contacting us, please, be sure that these leaks are not forced.

The biggest reported leak is that the global configuration is cached for next usage. If you do not want this feature, simply, call snd_config_update_free_global() after all snd_*_open*() calls. This function will free the cache.

Answer 3

Perhaps this will work (source):

diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c

--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2171,7 +2171,12 @@ static int snd_pcm_open_conf(snd_pcm_t **pcmp, const char *name,
        if (open_func) {
                err = open_func(pcmp, name, pcm_root, pcm_conf, stream, mode);
                if (err >= 0) {
-                       (*pcmp)->open_func = open_func;
+                       if ((*pcmp)->open_func) {
+                               /* only init plugin (like empty, asym) */
+                               snd_dlobj_cache_put(open_func);
+                       } else {
+                               (*pcmp)->open_func = open_func;
+                       }
                        err = 0;
                } else {
                        snd_dlobj_cache_put(open_func);

I tried it myself, but to no avail. My core temp heats up ~10 °F, most likely due to similar memory leak. Here's some of what valgrind gave me, even after using the patch above:

    ==869== 16,272 bytes in 226 blocks are possibly lost in loss record 103 of 103
    ==869==    at 0x4C28E48: calloc (vg_replace_malloc.c:566)
    ==869==    by 0x5066E61: _snd_config_make (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5066F58: _snd_config_make_add (in /usr/lib64/libasound.so.2)
    ==869==    by 0x50673B9: parse_value (in /usr/lib64/libasound.so.2)
    ==869==    by 0x50675DE: parse_array_def (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067680: parse_array_defs (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067A8E: parse_def (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
    ==869==    by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)

The number of bytes lost just keeps going up and up.