valgrind能检测未初始化值使用，报“use of uninitialised value”，但需加--track-origins=yes才能追踪源头；默认仅定位触发行，不开该选项无法得知值最初来自哪个变量或malloc；编译必须带-g，否则无行号信息。
Valgrind 能直接报出未初始化变量的使用，但需要开启 --track-origins=yes 才能准确定位源头。
看到 "Use of uninitialised value" 就是未初始化变量被读取了
Memcheck 在运行时会监控所有内存读写。一旦某段代码读取了尚未写入值的内存（比如局部变量声明后直接用、malloc 分配后没赋值就 printf），就会触发这个错误。典型输出类似：
==12345== Use of uninitialised value of size 8 ==12345== at 0x400526: main (badloop.c:9) ==12345== by 0x52E9F82: __libc_start_main (in /usr/lib/libc-2.33.so)
注意：它不区分“变量没初始化”和“堆内存没初始化”，只认“这块内存从未被写过就被读了”。所以 int x; 和 int* p = malloc(sizeof(int)); printf("%d", *p); 都会触发同一类提示。
不加 --track-origins=yes 只能知道哪行出问题，不知道为什么
默认情况下，Valgrind 知道“这里用了未初始化值”，但不会告诉你这个值最初是从哪来的。比如：
-
int a; int b = a + 1;→ 报错在b = a + 1行 - 但如果
a是从函数返回值或结构体字段传进来的，没开--track-origins=yes就看不到源头
加上后，会多一段 by 0x40051A: main (badloop.c:6) 类似的追踪链，甚至指出是哪个 malloc 或哪个栈变量漏赋值了。
gcc -g 编译是必须的，否则行号和变量名全丢
Valgrind 依赖调试信息定位源码位置。没加 -g 编译，错误里只会显示 ??? 或地址，无法对应到 badloop.c:9 这样的行号。常见误操作：
- 用
gcc -O2编译后直接跑 Valgrind → 优化可能删掉变量或重排逻辑，导致误报或漏报 - 忘记
-g，只加了-O0→ 行号没了，只能靠地址反查，效率极低 - 静态链接 libc（
-static）→ 某些版本 Valgrind 无法解析符号，建议动态链接
它检测不到所有“未初始化”场景
Memcheck 的能力边界要心里有数：
- 不检查全局/静态变量的零初始化（C/C++ 标准规定它们默认为 0，不算“未初始化”）
- 不检查栈上数组的越界读（比如
int a[3]; printf("%d", a[5]);），只检越界写和堆内存相关操作 - 对
union成员的“未初始化”判断可能不准，取决于当前活跃成员 - 如果变量被编译器优化掉（如未使用的局部变量），Valgrind 根本看不到它
真正难缠的是那些跨函数传递、中间经过指针转换、或混在结构体 padding 里的未初始化字节 —— 这时候 --track-origins=yes 加 -g 编译就是唯一靠谱的组合。
