能，Valgrind通过Memcheck工具在程序退出时扫描堆内存，对malloc/calloc/realloc分配后未free的数组准确报告为“definitely lost”或“still reachable”，前提是编译带-g调试信息、运行时启用--leak-check=full且程序正常结束。
Valgrind 能直接发现 malloc 后没 free 的数组吗？
能，但前提是数组是用 malloc、calloc 或 realloc 分配的堆内存。Valgrind 不检查栈上数组（比如 int arr[100]），也不管 new（C++）——除非你用 --tool=memcheck 并链接了 C++ 运行时，且开启 --leak-check=full。
关键判断依据：只要内存来自堆、程序退出时仍被指针持有且未 free，Valgrind 就会归类为 “definitely lost” 或 “still reachable”，取决于指针是否还在作用域内。
怎么运行才能让 Valgrind 报出未释放的数组？
必须启用内存泄漏检测，且不能跳过退出时的扫描。默认 valgrind ./a.out 不报告泄漏，得加参数：
-
--leak-check=full：显示每块泄漏内存的分配调用栈 -
--show-leak-kinds=all：不放过definitely lost、indirectly lost、possibly lost和still reachable -
--track-origins=yes（可选）：对未初始化值有用，和泄漏无关，别加错目标
典型命令：valgrind --leak-check=full --show-leak-kinds=all ./my_program
注意：如果程序里用了 exit() 早退，或有 fork 后子进程没 wait，Valgrind 可能只检查主进程退出点，漏掉子进程的泄漏——得确保程序自然结束 main。
常见误判和真漏泄的区别在哪？
Valgrind 把泄漏分四类，重点看前两类：
-
definitely lost：指针已出作用域，内存彻底“丢”了（比如局部指针分配后没 free 就 return） -
indirectly lost：指向它的指针被definitely lost，形成链式泄漏（如结构体成员指针没释放） -
still reachable：全局变量、static 局部变量或 main 栈帧里的指针还存着——不是 bug，是设计如此（比如缓存数组） -
suppressed：被 suppress 文件过滤了，通常不用管
示例：一个函数里 int *p = malloc(1024); return;，Valgrind 会标 definitely lost，并指出在第几行调用 malloc；但如果写成 static int *p = malloc(1024);，就归为 still reachable。
为什么加了参数还是没报泄漏？
几个高频原因：
- 程序崩溃退出（段错误、abort）导致 Valgrind 来不及做退出扫描——先用
gdb或catchsegv定位崩溃点 - 用了
mmap、brk等系统调用绕过 malloc，Valgrind 默认不跟踪（需--trace-system=yes，但一般没必要） - C++ 里混用
new和free，或new[]配delete，Valgrind 能报 mismatch，但泄漏本身可能被掩盖 - 编译没关优化（
-O2以上），导致指针被优化掉，Valgrind 误判为still reachable——调试阶段坚持用-O0 -g
真正难搞的是跨 shared library 的分配/释放：比如库 A 用 malloc 分配，库 B 用 free 释放，但两个库链接了不同版本的 libc——Valgrind 会报 invalid free 或泄漏，得统一内存管理边界。
