ALSA - MEM泄漏？(alsa - mem leak?)

我一直在追逐一个内存泄漏（由“的valgrind --leak检查= YES”报道），它似乎是从ALSA到来。此代码已经在自由世界的一段时间，所以我猜它的东西，我做错了。

#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>

int main (int argc, char *argv[])
{
    snd_ctl_t *handle;

    int err = snd_ctl_open( &handle, "hw:1", 0 );
    printf( "snd_ctl_open: %d\n", err );

    err = snd_ctl_close(handle);
    printf( "snd_ctl_close: %d\n", err );
}

输出看起来是这样的：

[root@aeolus alsa]# valgrind --leak-check=yes ./test2
==16296== Memcheck, a memory error detector
==16296== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==16296== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16296== Command: ./test2
==16296==
snd_ctl_open: 0
snd_ctl_close: 0
==16296==
==16296== HEAP SUMMARY:
==16296==     in use at exit: 22,912 bytes in 1,222 blocks
==16296==   total heap usage: 1,507 allocs, 285 frees, 26,236 bytes allocated
==16296==
==16296== 4 bytes in 2 blocks are possibly lost in loss record 1 of 62
==16296==    at 0x4007100: malloc (vg_replace_malloc.c:270)
==16296==    by 0x340F7F: strdup (in /lib/libc-2.5.so)
==16296==    by 0x624C6B5: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624CA5B: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296==    by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296==    by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296==    by 0x804852F: main (test2.cpp:9)

并继续对某些网页

==16296== 2,052 bytes in 57 blocks are possibly lost in loss record 62 of 62
==16296==    at 0x4005EB4: calloc (vg_replace_malloc.c:593)
==16296==    by 0x624A268: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624A38F: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624CA33: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624CCC9: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296==    by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296==    by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296==    by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296==    by 0x804852F: main (test2.cpp:9)
==16296==
==16296== LEAK SUMMARY:
==16296==    definitely lost: 0 bytes in 0 blocks
==16296==    indirectly lost: 0 bytes in 0 blocks
==16296==      possibly lost: 22,748 bytes in 1,216 blocks
==16296==    still reachable: 164 bytes in 6 blocks
==16296==         suppressed: 0 bytes in 0 blocks
==16296== Reachable blocks (those to which a pointer was found) are not shown.
==16296== To see them, rerun with: --leak-check=full --show-reachable=yes
==16296==
==16296== For counts of detected and suppressed errors, rerun with: -v
==16296== ERROR SUMMARY: 56 errors from 56 contexts (suppressed: 19 from 8)

这是约，因为我在一个项目中使用ALSA，开始看到了这个巨大的泄漏......或者说，泄漏的至少报告。

所以，问题是：这是我的，ALSA或者说在这里有问题的valgrind？

Answer 1:

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

  Memory leaks - really? ---------------------- 
需要注意的是一些开发商认为的ALSA库有一些内存泄漏。当然，这可能是事实，但与我们联系之前，请确保这些泄漏不是被迫。
最大的报道泄漏，全球配置缓存下次使用。如果你不想要这个功能，简单地说，叫snd_config_update_free_global（）所有SND _ * _ *开放后（）调用。该功能将释放缓存。

Answer 2:

最大的报道泄漏，全球配置缓存下次使用。

如果你不想要这个功能，只需调用snd_config_update_free_global()毕竟snd_*_open*()调用。

该功能将释放缓存。” <---- Valgrind的还是检测泄漏。

这可以，如果你拨打固定snd_config_update_free_global() 后 snd_pcm_close(handle);

Answer 3:

也许这将工作（来源）：

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);

我没有尝试过自己，但无济于事。我的核心温度加热至10°F，最有可能是由于类似的内存泄漏。下面是一些什么样的valgrind给了我，即使使用上面的补丁后：

    ==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)

字节数仅仅丢掉继续上升了起来。

文章来源: alsa - mem leak?