valgrind 能检测动态库问题的前提是库未被 dlclose 且编译带 -g：需注释所有 dlclose、主程序和库均带调试信息，再通过测试桩调用 dlopen/dlsym 触发执行。
Valgrind 本身不直接检查 .so 文件，它只能检测**运行时加载并实际执行的代码**。所以想查动态库的问题，关键不是“怎么让 Valgrind 扫描 so”，而是“怎么让动态库的代码在 Valgrind 下跑起来，并且能看清调用栈和符号”。否则你只会看到一堆 ???。
动态库符号全变成 ??? 的根本原因
Valgrind 报错里出现大量 ???（比如 by 0x5885956: ???），通常不是编译问题，而是动态库被卸载了。Valgrind 在程序退出前会尝试读取共享对象的调试信息；一旦你调用了 dlclose() 或者 glib 的 g_module_close()，符号表就被丢弃，后续 leak report 或错误堆栈就再也补不回源码位置。
- 典型触发场景：程序中显式调用
dlclose(handle)后再退出 - 即使你编译时加了
-g、没 strip、也用了--num-callers=20，只要库被dlclose过，符号就没了 -
LD_PRELOAD注入的库不会被自动dlclose，所以它的符号通常能保留
让动态库函数调用栈可读的实操条件
必须同时满足这三点，Valgrind 才能打出带文件名和行号的堆栈：
- 动态库编译时带
-g（不是只给主程序加） - 动态库未被
dlclose()—— 最简单办法是**注释掉所有dlclose调用**，哪怕只是临时测试 - 主程序也得带
-g，且不能 strip；链接时不要加-Wl,-z,relro等可能干扰符号读取的选项
例如，如果你用 dlopen("libfoo.so", RTLD_LAZY)，就别跟一句 dlclose(handle) —— 让它活到进程自然退出。
检测动态库内存问题的最小可行路径
你无法把 valgrind --leak-check=full ./libfoo.so 这样跑起来。正确做法是写一个极简测试桩（test harness），只做一件事：加载库 + 调用目标函数 + 退出。
- 写一个
test_foo.c，用dlopen/dlsym调用你想测的函数（比如init()、process()） - 编译时链接
-ldl，但**不链接-lfoo**（避免静态绑定，确保走 dlopen 路径） - 命令：
gcc -g test_foo.c -ldl -o test_foo && valgrind --leak-check=full --track-origins=yes ./test_foo - 如果库内部有
memcpy重叠警告（如Source and destination overlap in memcpy），这个方式也能捕获，且堆栈能定位到库内具体调用点
遇到 memcpy 重叠等底层报错时怎么定位
像 Source and destination overlap in memcpy(0x4f35880, 0x4f35880, 163840) 这类错误，Valgrind 只能告诉你调用发生在哪一层，但没法自动指出是哪个业务函数传错了指针。这时要结合两件事：
- 确认你的动态库是否导出了符号（
nm -D libfoo.so | grep your_func），否则dlsym拿不到地址，调用会失败或跳转到随机位置 - 在测试桩里，对关键参数做日志输出或断言，比如打印传给库函数的
src和dst地址，看它们是否意外相等 - 若仍不确定，用
LD_PRELOAD写个轻量 hook（比如拦截memcpy），在真正调用前打日志，能快速验证是不是上层传参错误
最常被忽略的一点：动态库的调试信息存活时间，完全取决于它是否被 dlclose —— 不是编译选项决定的，是运行时行为决定的。这点比加多少个 -g 都关键。
