alsa – mem泄漏?

我一直在追逐内存泄漏(由'valgrind –leak-check = 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,并开始看到这个巨大的泄漏…或者至less是泄露的报告。

所以问题是:是我,ALSA还是valgrind在这里有问题?

Solutions Collecting From Web of "alsa – mem泄漏?"

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

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

请注意,有些开发人员认为ALSA库有一些内存泄漏。 当然,这可能是事实,但在联系我们之前,请确保这些泄漏不是被迫的。

报告的最大泄漏是全局配置被缓存下次使用。 如果您不想使用此功能,只需在所有snd _ * _ open *()调用之后调用snd_config_update_free_global()即可。 这个函数将释放缓存。

也许这将工作( 来源 ):

 diff --git a/src/pcm/pcm.cb/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 == 226块中的16,272字节可能会丢失在103中的103条记录中
     == 869 == at 0x4C28E48:calloc(vg_replace_malloc.c:566)
     == 869 == by 0x5066E61:_snd_config_make(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5066F58:_snd_config_make_add(在/usr/lib64/libasound.so.2中)
     == 869 == by 0x50673B9:parse_value(在/usr/lib64/libasound.so.2中)
     == 869 == by 0x50675DE:parse_array_def(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5067680:parse_array_defs(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5067A8E:parse_def(在/usr/lib64/libasound.so.2中)
     == 869 == by 0x5067BC7:parse_defs(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5067A6F:parse_def(在/usr/lib64/libasound.so.2中)
     == 869 == by 0x5067BC7:parse_defs(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5067A6F:parse_def(位于/usr/lib64/libasound.so.2)
     == 869 == by 0x5067BC7:parse_defs(位于/usr/lib64/libasound.so.2) 

丢失的字节数量不断增加。

报告的最大泄漏是全局配置被缓存下次使用。

如果你不想要这个功能,只需在snd_*_open*()调用之后调用snd_config_update_free_global()

此功能将释放缓存。“<—- Valgrind仍然检测到泄漏。

如果你 snd_pcm_close(handle); 之后调用snd_config_update_free_global() 这个问题就可以解决snd_pcm_close(handle);