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==226ブロックの16,272バイトが103の損失レコード103で失われる可能性があります
    == 869 == 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内）

失われたバイト数は増え続けます。

于 2012-11-29T07:19:30.557 に答える