Valgrind 不能直接检查正在运行的程序，必须在启动时介入；它通过动态插桩跟踪内存操作，不支持 attach 到已运行进程，正确做法是用 valgrind 包裹重新启动目标程序。
Valgrind 能不能直接查正在运行的程序
不能。Valgrind 必须在目标程序启动时就介入，它通过动态插桩（instrumentation）重写二进制指令来跟踪内存操作，因此无法 attach 到已运行的进程。如果你看到 valgrind --pid=1234 这类写法，那是无效的——valgrind 命令根本不支持 --pid 参数。
正确做法是：停止当前程序，改用 valgrind 包裹启动。例如原命令是 ./myapp --config=config.yml，排查时应运行：
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose ./myapp --config=config.yml
-
--leak-check=full：启用完整泄露检测（默认是 summary） -
--show-leak-kinds=all：显示definitely lost、indirectly lost、possibly lost、still reachable四类结果 -
--track-origins=yes：定位未初始化内存的来源（对Conditional jump or move depends on uninitialised value类错误很关键） - 避免加
--tool=memcheck：这是默认工具，显式指定不必要，还可能因拼写错误导致失败
为什么 valgrind 报 “Invalid read/write” 却没崩
因为 Valgrind 的 Memcheck 工具在用户态拦截所有内存访问，比操作系统更早发现越界行为。程序没崩溃，只是还没踩到保护页或触发 SIGSEGV——但行为已是未定义（UB），后续可能随机 crash、数据错乱或静默污染。
常见诱因包括：
- 使用了
malloc分配但未free的指针，之后又继续读写（尤其多线程中释放后未置 NULL） - 数组下标越界，比如
buf[1024]定义却访问buf[1024]（合法索引是 0–1023） - C++ 中
std::vector::data()返回裸指针，但 vector 被 move 或 resize 后原指针失效 - 结构体内存对齐 padding 导致
memcpy覆盖相邻字段
这类问题在 valgrind 下会明确报出 Invalid write of size X 并附调用栈，比 core dump 更早暴露隐患。
Valgrind 检测 C++ 智能指针泄漏是否可靠
基本可靠，但有前提：必须用标准库实现（libstdc++ / libc++），且编译时未定义 _GLIBCXX_DEBUG 等调试宏干扰内部结构。
Valgrind 不解析 C++ 语义，它只跟踪 malloc/new 和 free/delete 的底层调用。只要智能指针析构时正确调用了 delete（如 std::unique_ptr、std::shared_ptr 的默认 deleter），就不会被记为 leak。
- 若自定义 deleter 里漏掉
delete，valgrind 仍会报definitely lost -
std::shared_ptr循环引用不会被 valgrind 标记为 leak（因为内存仍被引用），但会导致对象永不析构——需配合其他手段（如添加 weak_ptr 断点或用 AddressSanitizer + UBSan）交叉验证 - 避免用
std::make_shared创建对象后，又用裸指针new手动管理同一块内存，否则 valgrind 会误判
性能太慢、跑不动怎么办
Valgrind 的 Memcheck 工具会让程序变慢 20–50 倍，内存占用翻倍，对 I/O 密集或实时性要求高的程序几乎不可行。
可切换更轻量的替代方案：
- 先试
addr2line -e ./myapp 0x401234解析 core 文件地址，快速定位崩溃点 - 用
gcc -fsanitize=address,undefined编译（ASan+UBSan），运行时开销仅 2–3 倍，能捕获多数内存错误，但不提供 leak summary - 对长期运行服务，可结合
/proc/PID/status中的VmRSS和cat /proc/PID/maps | grep heap | wc -l观察堆段增长趋势，再辅以pstack抓堆栈判断是否卡在某次分配 - 若必须用 valgrind，加
--run-libc-freeres=no（跳过 glibc 自清理）和--freelist-vol=10000000（增大空闲块缓存）可小幅提速
真正难的是那些只在特定输入路径触发、且泄露速度极慢的问题——这时候 valgrind 的 --log-file=valgrind-out.%p 配合定时采样 + diff 内存块摘要，比单次全量扫描更实用。
