4

我一直在寻找内存泄漏（由 '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 并开始看到这个巨大的泄漏......或者至少是所说泄漏的报告。

所以问题是：是我、ALSA 还是 valgrind 有问题？

4

3 回答 3

3

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

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

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

报告的最大泄漏是全局配置被缓存以备下次使用。如果您不想要此功能，只需在所有 snd_*_open*() 调用后调用 snd_config_update_free_global()。此函数将释放缓存。

于 2012-11-20T19:31:20.823 回答
1

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

如果您不想要此功能，只需snd_config_update_free_global()在所有呼叫后呼叫即可snd_*_open*()。

此函数将释放缓存。” <---- Valgrind 仍然检测到泄漏。

如果您在之后致电，则可以解决此问题snd_config_update_free_global() snd_pcm_close(handle);

于 2017-02-17T01:16:25.290 回答
0

也许这会起作用（来源）：

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== 103 的丢失记录 103 中可能丢失了 226 个块中的 16,272 个字节
    ==869== 在 0x4C28E48: calloc (vg_replace_malloc.c:566)
    ==869== 由 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 (in /usr/lib64/libasound.so.2)
    ==869== 由 0x50675DE：parse_array_def（在 /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)

丢失的字节数不断增加。

于 2012-11-29T07:19:30.557 回答