Valgrind无泄漏函数名/行号问题求助：编译与工具使用排查

一、先确认编译产物是否包含完整调试信息 #

你的Makefile里加了-g -O0，但得确保这些参数真的生效：

1. 编译时查看输出命令，确认每个.cpp编译成.o的命令里确实带有-g参数。
2. 用工具验证调试信息：

   # 检查可执行文件是否有调试段
   readelf -S ./program | grep -i debug
   # 或者用gdb测试
   gdb ./program -ex "list main" -ex quit
   

   如果gdb能显示main函数的代码行，说明调试信息正常；如果不行，检查Makefile是否有语法错误（比如规则行是否用Tab缩进，Makefile要求规则行必须用Tab而非空格）。

二、调整Valgrind命令，强制显示完整调用栈 #

ARM64架构（Jetson设备）上的Valgrind默认可能不会显示完整调用栈，修改命令如下：

valgrind --leak-check=full --show-leak-kinds=all --verbose --log-file=valgrind-out2.txt --track-origins=yes --num-callers=20 ./program

• --num-callers=20：增加显示的调用栈层数，帮你定位更上层的调用来源
• --track-origins=yes：增强内存泄漏的栈信息追踪能力

三、区分泄漏来源：自己的代码还是依赖库 #

从你给出的Valgrind输出看，有部分泄漏来自libgobject-2.0.so（GTK/GObject相关），还有operator new的调用可能来自OpenCV/JetsonGPIO的内部实现：

1. 写最小测试程序排查库泄漏：

   • 仅链接OpenCV的测试代码：

     #include <opencv2/core/core.hpp>
     int main() {
         cv::Mat test_mat(100, 100, CV_8UC3);
         return 0;
     }
     

     用你的Makefile逻辑编译后跑Valgrind，如果同样出现泄漏，说明是OpenCV本身的问题（部分ARM版本的OpenCV存在已知的小泄漏，或者需要显式调用资源释放）。
   • 同理测试JetsonGPIO的最小程序，确认是否是GPIO库的泄漏。

2. 如果是库本身的小泄漏，可忽略（只要不是大量持续泄漏），重点关注来自你自己代码的调用栈。

四、排查智能指针的潜在问题 #

你说没直接用new，但智能指针的误用也会导致泄漏：

• 循环引用：两个std::shared_ptr互相指向对方，导致引用计数无法归0，比如：

  class A { public: std::shared_ptr<B> b; };
  class B { public: std::shared_ptr<A> a; };
  // 创建后互相赋值，就会形成循环引用
  

• 错误的删除器：如果用智能指针包裹了第三方库的C风格对象（比如OpenCV的C API结构体），默认的delete可能无法正确释放，需要自定义删除器：

  // 比如OpenCV的C风格IplImage
  std::shared_ptr<IplImage> img(cvLoadImage("test.jpg"), cvReleaseImage);
  

• 裸指针重复管理：用std::shared_ptr管理了已经被其他智能指针或手动delete的裸指针，导致双重释放或泄漏。

五、Makefile的潜在验证点 #

确认pkg-config的输出是否正确：

# 检查OpenCV的编译参数
pkg-config --cflags opencv4
# 检查链接参数
pkg-config --libs opencv4

如果输出为空或错误，说明OpenCV的pkg-config配置有问题，需要手动指定路径。

内容的提问来源于stack exchange，提问作者KTBM