只是一个循环,33次泄漏

DCM*_*xxx 5 c macos valgrind memory-leaks

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

$> cat main.c
Run Code Online (Sandbox Code Playgroud)
#include <stdio.h>   
int main(int ac, char **av) {
    for (int i = 0; i < ac; i++)
        printf("%s\n", av[i]);
    return 0;
}
Run Code Online (Sandbox Code Playgroud)
$> gcc main.c -std=c99
$> valgrind ./a.out hello my friends
Run Code Online (Sandbox Code Playgroud)

这是结果:

==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)
Run Code Online (Sandbox Code Playgroud)

如果有人知道为什么,并且可以解释我这些泄漏的来源,我会感激不尽!

祝你有美好的一天 :-)

Jan*_*Jan 9

这些都不是泄漏.列出的对象still reachable应该不会给您带来麻烦.如果你在上面的行中有一个非零值,那么它应该响起警钟!

列出的33个块still reachable很可能是printf标准库在调用内部分配的一些块 .没什么好担心的.

考虑一下这个类似问题的答案.