必须用-g编译并保留调试符号，禁用优化（-o0），避免strip；启用--read-var-info=yes和--track-origins=yes可增强行号显示，若仍缺失可用addr2line手动解析地址。
Helgrind 报告里 address is 0x... in thread N 这行没代码位置，怎么办
Helgrind 默认不带源码行号，是因为它不自动读取调试符号（debug info）。你看到的堆栈里只有地址和函数名（比如 pthread_mutex_lock），但看不到 main.c:42 这种具体行——这不是 Helgrind 漏了，是你编译时没给它留线索。
- 必须用
-g编译（GCC/Clang 都要），否则连函数名都可能模糊成??? - 禁用优化：
-O0最稳妥；-O1有时还能对上行号，-O2+会让变量重排、内联、跳转，Helgrind 的堆栈映射大概率错位 - 确保没 strip：链接时别加
-s，运行文件得保留.debug_*节区
怎么让 Helgrind 输出带文件和行号的堆栈
光有 -g 不够，还得告诉 Helgrind 别省略路径信息。默认它会把 /home/user/proj/src/lock.c 缩成 lock.c，一旦项目里有同名文件（比如多个 utils.c），你就没法分清是哪个。
- 启动时加
--track-origins=yes（虽主要为 Memcheck 设计，但能强化 Helgrind 的堆栈解析） - 关键参数：
--read-var-info=yes—— 它会让 Helgrind 尝试从 DWARF 中提取变量作用域和行号，对定位竞争点附近的读写操作特别有用 - 如果仍只显示函数名，用
addr2line -e your_program 0x12345678手动查地址，前提是二进制带调试信息
竞争报告里 “conflicting accesses” 指哪两行代码
Helgrind 的典型报错像这样：
==12345== Possible data race during read of size 4 at 0x1093A8 by thread #2 ==12345== Locks held: none ==12345== at 0x40062E: worker (main.c:33) ==12345== by 0x4E426DA: start_thread (in /usr/lib/libpthread-2.31.so) ==12345== ==12345== This conflicts with a previous write of size 4 at 0x1093A8 by thread #1 ==12345== Locks held: none ==12345== at 0x40060C: main (main.c:25)
注意两个 at 行：main.c:33 是线程 #2 读的位置，main.c:25 是线程 #1 写的位置——这两行就是竞争发生的**实际代码行**。Helgrind 不会说“你在第 28 行漏加锁”，它只告诉你“这里读，那里写，中间没同步”，所以你要人工检查这两行之间是否共享变量、是否缺少互斥保护。
- 如果堆栈里出现
???，说明对应地址没调试信息，回去检查编译命令是否漏-g或被后续 strip 掉了 - 如果两行都在同一个函数里（比如都在
process_queue()），重点看那个函数里哪些变量被多线程并发访问，尤其注意传入的指针参数是否指向同一块内存 - Helgrind 不报“谁该加锁”，只报“谁在无保护下碰了同一地址”。加锁位置通常得在访问前，而不是在行号那行里面
为什么修复后 Helgrind 还报老地址
常见于增量编译后没 clean 二进制，或者运行了旧版本程序。Helgrind 不会校验源码时间戳，它只分析你传给它的可执行文件。
- 改完代码务必重新完整编译：
make clean && make，避免 .o 文件残留旧调试信息 - 确认运行的是刚编译的版本：
ls -l ./your_program看修改时间，或readelf -S ./your_program | grep debug验证 .debug_* 节存在 - 如果用了构建系统（CMake/Bazel），检查是否启用了
RELWITHDEBINFO这类模式——它可能默认关掉-g，得显式加-DCMAKE_BUILD_TYPE=Debug
最隐蔽的坑是动态链接的共享库没带调试信息。如果竞争发生在第三方库（比如 libcurl）里，Helgrind 只能报到库函数入口，你得自己查该库的源码或换用带 debuginfo 的包（如 Ubuntu 的 libcurl4-dbgsym）。
