1

ファイルから読み取り、アイテムをキューに保存してから出力するプログラムがあります。私はこれをvalgrindから取得しています：

 HEAP SUMMARY:
     in use at exit: 302 bytes in 14 blocks
   total heap usage: 30 allocs, 16 frees, 1,230 bytes allocated

 302 bytes in 14 blocks are definitely lost in loss record 1 of 1
    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
    by 0x372167FB41: strdup (strdup.c:43)
    by 0x400A6A: addtoqueue(main.c:30)
    by 0x400B5A: addfiletoqueue(main.c:45)
    by 0x400C27: main (main.c:62)

 LEAK SUMMARY:
    definitely lost: 302 bytes in 14 blocks
    indirectly lost: 0 bytes in 0 blocks
      possibly lost: 0 bytes in 0 blocks
    still reachable: 0 bytes in 0 blocks
         suppressed: 0 bytes in 0 blocks

main.cの62行目

addfiletoqueue (queue, argv[argi]);

main.cの45行目

addtoqueue (queue, file, filename);

main.cの30行目

readline = strdup (buffer);
assert (readline != NULL);
queue_add (queue, readline);

リードラインを解放する必要がありますか？

4

4 に答える 4

5

はい、strdup()必要なメモリを動的に割り当てますfree()。リンクされた参照ページから：

strdup() 関数は、文字列 s の複製である新しい文字列へのポインタを返します。新しい文字列のメモリは malloc(3) で取得され、free(3) で解放できます。

于 2013-02-25T09:36:05.147 に答える
5

readline を解放する必要がありますか?

はい。のマニュアルページにstrdupは、戻り値にメモリを動的に割り当てると記載されています。したがって、プログラムの後半でこれを呼び出す必要がありfreeます。

于 2013-02-25T09:36:10.947 に答える
4

はい、使い終わったら解放する必要があります。

これはおそらく ではなくaddfiletoqueue()、プログラムの終了時です。ただし、メモリが「確実に失われている」という診断は、さらに問題がある可能性があることを意味します。おそらく、途中でポインターを失う可能性があります。

基本的にはandをstrdup()呼び出すだけなので、使い終わったときに必要なヒープからメモリを割り当てています。malloc()strcpy()free()

また、readlineかなり標準化された関数名でもあるため、非常に悪い変数名です。

于 2013-02-25T09:36:27.640 に答える
1

strdup() 関数は、文字列 s の複製である新しい文字列へのポインタを返します。新しい文字列のメモリは malloc(3) で取得され、free(3) で解放できます。

http://www.kernel.org/doc/man-pages/online/pages/man3/strdup.3.html

Valgrind の「損失記録で確実に失われました」は、コード リーク メモリを示しています。したがって、valgrind からのこのようなエラーに対処する必要があります...

于 2013-02-25T09:38:00.187 に答える