Question

在我的Mac上看起来很奇怪：

$> cat main.c

#include <stdio.h>   
int main(int ac, char **av) {
    for (int i = 0; i < ac; i++)
        printf("%s\n", av[i]);
    return 0;
}

$> gcc main.c -std=c99
$> valgrind ./a.out hello my friends

结果如下：

==725== Memcheck, a memory error detector
==725== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==725== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==725== Command: ./a.out hello my friends
==725== 
--725-- ./a.out:
--725-- dSYM directory is missing; consider using --dsymutil=yes
./a.out
hello
my
friends
==725== 
==725== HEAP SUMMARY:
==725==     in use at exit: 6,146 bytes in 33 blocks
==725==   total heap usage: 33 allocs, 0 frees, 6,146 bytes allocated
==725== 
==725== LEAK SUMMARY:
==725==    definitely lost: 0 bytes in 0 blocks
==725==    indirectly lost: 0 bytes in 0 blocks
==725==      possibly lost: 0 bytes in 0 blocks
==725==    still reachable: 6,146 bytes in 33 blocks
==725==         suppressed: 0 bytes in 0 blocks
==725== Rerun with --leak-check=full to see details of leaked memory
==725== 
==725== For counts of detected and suppressed errors, rerun with: -v
==725== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

如果有人知道原因，并且可以解释我这些泄漏的来源，我会很感激!!

祝你有个美好的一天： - ）

Answer 1

"still reachable"当程序终止时，实在没什么可担心的。

"still reachable"表示已分配的内存尚未释放，但仍有指向此内存的指针。因此，valgrind并没有将其标记为真正的记忆“泄漏”。

浪费时间通常是浪费时间：在应用程序结束之前分配的内存，分配的内存无论如何都将返回到操作系统，因为应用程序正在终止。

只是一个循环，33次泄漏

1 个答案: