能，Valgrind在运行时通过Memcheck检测到new[]与delete混用会直接报“mismatched free()/delete/delete[]”错误，需带-g编译才能定位源码行号。
Valgrind 能直接报出 new/delete 混用吗
能，但只在运行时触发具体内存操作时才暴露。Memcheck 会把 new 和 delete 视为底层堆分配/释放动作，一旦你用 new[] 分配却调用 delete（而非 delete[]），Valgrind 在执行该 delete 时就会记录“mismatched free() / delete / delete[]”错误——不是编译警告，是实打实的运行时报错。
必须加 -g 编译，否则连哪行出问题都看不到
不带调试信息编译的二进制，Valgrind 只能显示汇编地址或问号，根本无法定位到源码行。哪怕只是临时验证，也务必加上 -g：
g++ -g -O0 buggy.cpp -o buggy
-
-O0推荐加上：优化可能让某些错误被掩盖（比如未初始化变量被优化掉） - 不用改源码、不用链接额外库、不依赖 ASan 那类编译器插件
- 如果用了 C++17 或更新标准，
std::vector或std::unique_ptr<t></t>自动规避这类问题，但 Valgrind 仍是你验证遗留代码的底线工具
典型报错长什么样？怎么读
运行 valgrind --tool=memcheck ./buggy 后，关键错误段类似：
==12345== Mismatched free() / delete / delete [] ==12345== at 0x4C30D3B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12345== by 0x1091A9: main (buggy.cpp:8) ==12345== Address 0x4f3a040 is 0 bytes inside a block of size 40 alloc'd ==12345== at 0x4C3017F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12345== by 0x10919E: main (buggy.cpp:7)
重点看三行：
-
Mismatched free() / delete / delete []—— 这就是结论句 -
Address ... is 0 bytes inside a block of size 40 alloc'd—— 提示分配和释放位置不匹配 - 两处
main (buggy.cpp:7)和main (buggy.cpp:8)—— 行号对得上，说明-g生效了
为什么有时候没报错？不是所有混用都一定触发
Valgrind 不是静态扫描器，它只监控实际发生的内存操作。以下情况可能导致漏报：
- 混用发生在未执行的分支里（比如 if 条件为 false）
- 对象是 POD 类型（如
int[]），delete调用虽不规范但没触发析构逻辑，Valgrind 可能只报 warning 级别甚至跳过 - 程序在触发
delete前就崩溃或提前退出 - 用了自定义分配器且绕过了 malloc/new hook（Valgrind 默认只拦截标准堆接口）
真正危险的是类类型数组：只调第一个对象析构函数，其余对象资源泄漏 + 内存结构损坏——这种 Valgrind 通常能稳稳捕获。
