helgrind 默认输出人类可读文本而非结构化格式，最可靠保存方式是使用 --log-file=file 将报告写入指定文件；--xml=yes 对 helgrind 无效，仅 memcheck 和 callgrind 支持 xml；配合 --trace-children 时建议用 --log-file=%p 避免日志混杂。
Helgrind 默认不生成可保存的结构化报告
Helgrind 本身不直接输出 JSON/XML 等便于后续处理的格式，它的报告默认是人类可读的文本流，直接打印到 stderr。想“保存报告”，本质是重定向输出或启用日志机制——但要注意：不是所有选项都对 Helgrind 生效。
--log-file=file 是最常用且可靠的方式
这个选项在 Helgrind 下完全可用，会把全部检测输出（包括线程竞争警告、栈回溯、锁状态摘要）写入指定文件：
valgrind --tool=helgrind --log-file=helgrind-report.txt ./my_program
- 必须用
--log-file，--log-fd在多数场景下不如它稳定，尤其涉及子进程或重定向复杂时 - 文件路径需有写权限；若路径含目录，请确保目录已存在，Helgrind 不自动创建父目录
- 输出内容包含时间戳、线程 ID、冲突内存地址、相关锁变量名（如果符号未剥离），但不包含机器可解析的字段分隔符
XML 输出对 Helgrind 无效，别试 --xml=yes
虽然 --xml=yes 在 Memcheck 下能启用 XML 报告，但它对 Helgrind 不起作用——运行时会静默忽略，或报错退出（取决于 Valgrind 版本）。官方文档明确说明 XML 支持仅限于 Memcheck 和 Callgrind。
- 尝试
valgrind --tool=helgrind --xml=yes ./a.out通常会看到类似错误：unknown option --xml或直接拒绝启动 - DRD 工具也**不支持**
--xml；目前只有 Memcheck 和 Callgrind 能输出 XML - 如果真需要结构化数据，得靠外部工具解析文本报告（比如用 Python 正则提取
==[0-9]+==行和Address 0x...行），而非依赖 Valgrind 原生导出
配合 --trace-children=yes 时，日志文件行为要特别注意
如果你的程序 fork 出子进程并继续多线程执行（比如某些服务模型），开启 --trace-children=yes 后，Helgrind 会对每个子进程单独分析，但所有输出仍混在同一个 --log-file 中，且不同进程的日志块没有清晰分隔符。
- 每个进程的报告开头会有类似
==12345== Thread #1 was created的标识，但没统一 header - 避免用
--log-file+--trace-children处理大型分布式测试——建议改用--log-file=$PID模式（Valgrind 支持%p占位符）：--log-file=helgrind-%p.log -
%p会被替换成子进程 PID，这样每个进程日志独立，排查竞态时不会串行干扰
Helgrind 的报告保存关键在于接受它的文本本质：它不是为自动化流水线设计的，而是为开发者快速定位竞态提供上下文完整的现场快照。真正容易被忽略的是 --log-file 路径权限和 --trace-children 下的命名冲突——这两个点卡住的人，远多于搞不定 XML 导出的。
