valgrind 不支持 attach 到已运行进程，必须从启动时介入；可行做法是用 valgrind 重启程序，配合 --trace-children=yes、-g 编译、合理信号配置及日志分割等措施降低影响。
怎么 attach 到正在运行的进程
Valgrind 本身不支持 attach 到已启动的进程（不像 gdb 或 strace），它必须从程序启动时就介入执行环境。这是由其工作原理决定的：Valgrind 通过模拟 CPU 执行指令，在程序第一条指令前就接管控制流，注入检测逻辑。所以“分析一个已经跑起来的长期服务”，不能靠事后 attach。
让长期运行程序被 Valgrind 包裹启动
真正可行的做法是重启程序，但用 valgrind 启动它，并确保它能稳定运行足够长时间来暴露问题。关键点在于避免干扰原有运行逻辑：
- 用
--trace-children=yes—— 如果你的程序会 fork 子进程（比如守护进程调用daemon()或 double-fork），不加这个选项会导致子进程脱离 Valgrind 监控，漏掉内存问题 - 避免使用
-O2或更高优化等级编译；必须带-g，否则错误堆栈无法定位到源码行 - 如果程序依赖信号（如
SIGHUP重载配置），Valgrind 默认会拦截部分信号；必要时加--sigill-handler=no或调整信号处理行为 - 对长时间运行场景，建议加
--log-file=valgrind.%p.log，避免输出刷屏，也方便按 PID 区分日志
如何减少 Valgrind 对长期运行程序的影响
Valgrind 的 Memcheck 工具会让程序变慢 10–50 倍，内存占用翻倍，这对持续数小时的服务很现实。不是所有问题都需要全程监控：
- 用
--time-stamp=yes加时间戳，便于在日志里圈出可疑时间段 - 若只关心某段时间内的泄漏，可在代码中插入
VALGRIND_DO_LEAK_CHECK宏（需包含valgrind/valgrind.h），主动触发检查点，而不是等退出时才汇总 - Massif 不适合长期运行：默认每百万指令采样一次，几小时下来文件巨大；改用
--massif-out-file=massif.%p.out --max-snapshots=20限制快照数量 - 对高吞吐服务，优先考虑
Callgrind+KCachegrind分析热点路径，比全量 Memcheck 更轻量
为什么不能靠 kill -STOP / -CONT 配合 Valgrind
有人尝试先 kill -STOP 进程，再用 valgrind --pid=<pid></pid>（这个选项根本不存在），这是常见误解。valgrind 命令行里没有 --pid 参数，官方也不提供 runtime 注入能力。强行中断+重加载只会丢失上下文，且 Valgrind 的内存影子区（shadow memory）完全重建，之前的状态不可追溯。
真正要观测“活”进程的内存趋势，应换用 /proc/<pid>/status</pid>、pmap、smaps_rollup 或 eBPF 工具（如 bpftrace 的 malloc 跟踪），Valgrind 不是为此设计的。
