我在我的程序中使用g ++中的AddressSanitizer，并且有一些输出我很难理解并采取行动。
之前我使用的是g ++ - 4.8.4，我很确定没有泄漏报告，但我最近改用g ++ - 5.2.1，现在我有了新的错误报告。我猜gcc5变得更好了。
然而，其中一些非常神秘，如：
== 8192 ==错误：LeakSanitizer：检测到内存泄漏
从以下分配的174个对象直接泄漏6960个字节： __interceptor_calloc中的＃0 0x7f4a73eac5b1（/usr/lib/x86_64-linux-gnu/libasan.so.2+0x945b1） ＃1 0x7f4a3ccd1d81（/usr/lib/x86_64-linux-gnu/dri/i965_dri.so+0x27ad81）
从以下分配的4个对象直接泄漏2560个字节： realloc中的＃0 0x7f4a73eac76a（/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9476a） ＃1 0x7f4a53c34839（/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1b839）
从以下各项分配的57个对象中直接泄漏2144个字节： malloc中的＃0 0x7f4a73eac44a（/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9444a） ＃1 0x7f4a5f242b7c（/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xbb7c）
下一个更清楚：
从以下分配的1个对象中直接泄漏512个字节： 运算符new中的＃0 0x7f4a73ead1ba（unsigned long）（/usr/lib/x86_64-linux-gnu/libasan.so.2+0x951ba） ...更多行在文件和调用堆栈中查明问题。
前三个报告是否与最后一个报告相关联？如果他们是独立的，有没有办法找出问题所在？
感谢。
答案 0 :(得分：0)
==8192==：PID
Direct leak of 6960 byte(s)：此报告的总泄漏内存
in 174 object(s)：共享相同堆栈跟踪（或堆栈跟踪的一部分）的不同分配的数量（可能是循环中的分配）
from: #0 [...]：堆栈跟踪。
这是对这里的内容的愚蠢解释。
您可能想知道的是：您泄漏的所有内容似乎都在i965_dri.so，Linux上的intel userland图形驱动程序以及其他X.org共享对象中。如果您没有释放一些openGL / GLX资源或者被LeakSanitizer视为泄漏，而是由intel驱动程序管理（可能是缓存或分配池），那么泄漏可能来自您的代码。
我要寻找的第一件事是openGL资源，它们在程序结束时仍处于活动状态并释放它们。如果您使用像Qt / ...这样的渲染或库，它可能会保留一些资源。
您是否正确关闭已分配的窗口，释放光标，......？