--track-origins=yes是唯一能追溯未初始化值来源的选项，它在启用后于错误报告末尾添加“uninitialised value was created by”追溯块，明确指出源头为栈分配、堆分配或memcpy等，但需配合-g编译且禁用高优化（如-o2）才能准确定位行号。
–track-origins=yes 是唯一有效方式
Valgrind Memcheck 默认不会告诉你未初始化值从哪来，只报 Use of uninitialised value 或 Conditional jump or move depends on uninitialised value(s)。必须显式启用 --track-origins=yes 才能回溯到变量声明、内存分配或拷贝点。
这个选项会显著拖慢运行速度（通常慢 2–3 倍），但对定位真实源头必不可少——尤其当未初始化值经过多次赋值、结构体嵌套或函数传参后已面目全非。
- 它只追踪“值”的传播路径，不追踪指针本身是否为空或越界
- 对栈上局部变量、堆内存、全局变量一视同仁，只要该值被读取且未初始化就会标记
- 输出中会出现
by 0x...: some_function (file.c:12)+uninitialised value was created by a heap allocation或stack allocation等提示
必须配合 -g 编译，否则行号失效
即使加了 --track-origins=yes，如果可执行文件没带调试信息，Valgrind 只能显示地址和符号名（如 main），无法定位到具体行号或变量名。编译时漏掉 -g 就等于白跑。
- gcc/clang 都需加
-g：例如gcc -g -o myapp myapp.c - 如果用了优化（如
-O2），建议暂时关闭；某些优化会合并/消除变量，导致源头行号偏移或丢失 - 静态链接的库若无调试符号，
--track-origins在其内部的传播链会中断，只显示“unknown”
常见误判场景：哪些“未初始化”其实不报错
Memcheck 不会对所有未初始化访问报警，它只在值“可能影响程序行为”时才触发，比如：
- 用未初始化值做条件跳转（
if (x > 0)） - 作为系统调用参数（
write(fd, buf, len)中buf内容未初始化） - 参与浮点运算或除法（
y = x / 2.0）
但以下情况通常不报：
- 未初始化变量被直接赋值（
int a; a = 5;） - 结构体部分字段未初始化，但只读取了已赋值字段
- 数组声明后仅写入部分元素，后续只读取已写位置
所以看到没报错，不等于代码安全；而报错了，说明该值确实流到了关键路径上。
输出里怎么认出真正的源头
启用 --track-origins=yes 后，错误报告末尾会多一段 Uninitialised value was created by 的追溯块。重点看最后一行：
-
a stack allocation→ 源头是某个函数里的局部变量，往上翻几行就能看到函数名和行号 -
a heap allocation→ 源头是malloc/new分配的内存，但内容没写就用了；此时要检查分配后是否 memset 或逐字段赋值 -
a memcpy/memmove→ 源缓冲区本身未初始化，问题前移一级 -
an unknown source→ 调试符号缺失，或来自内联汇编、寄存器直接赋值等 Valgrind 无法插桩的位置
注意：追溯链可能很长，但真正需要修复的往往只是最上游那个没初始化的动作，而不是中间每一步。
