2

I use AddressSanitizer from g++ on my program, and there are some outputs I have troubles understanding and acting on.

I was using g++-4.8.4 before, and I'm pretty sure there was no leak reports, but I recently switched to g++-5.2.1 and now I have new error reports. I guess gcc5 got better.

However, some of those are quite cryptic, like:

==8192==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 6960 byte(s) in 174 object(s) allocated from:
    #0 0x7f4a73eac5b1 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x945b1)
    #1 0x7f4a3ccd1d81  (/usr/lib/x86_64-linux-gnu/dri/i965_dri.so+0x27ad81)

Direct leak of 2560 byte(s) in 4 object(s) allocated from:
    #0 0x7f4a73eac76a in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9476a)
    #1 0x7f4a53c34839  (/usr/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1b839)

Direct leak of 2144 byte(s) in 57 object(s) allocated from:
    #0 0x7f4a73eac44a in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9444a)
    #1 0x7f4a5f242b7c  (/usr/lib/x86_64-linux-gnu/libxcb.so.1+0xbb7c)

Next one is more clear:

Direct leak of 512 byte(s) in 1 object(s) allocated from:
    #0 0x7f4a73ead1ba in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x951ba)
    ... more lines pinpointing the issue in a file and the call stack.

Are the first three reports linked to the last one? If they are independent, is there a way to find what is wrong?

Thanks.

user7610
  • 25,267
  • 15
  • 124
  • 150
Leherenn
  • 520
  • 5
  • 16

1 Answers1

3

==8192==: The PID

Direct leak of 6960 byte(s) : the total leaked memory for this report

in 174 object(s) : the number of distinct allocations that shares the same stacktrace (or a part of the stack trace) (could be allocations in a loop)

from: #0 [...] : the stack trace.

This is for a dumb explanation of what is here.

What you may want to know is this: all you leaks appears to be in the i965_dri.so, the intel userland graphic driver on Linux, and other X.org shared objects. The leak could then either comes from your code, if you don't free some openGL/GLX resources or counted as leak by LeakSanitizer but is instead managed by the intel driver (maybe as a cache or an allocation pool).

The first thing I would look for is the openGL resources that are still actives at the end of the program and free them. If you use a render or libraries like Qt/..., it may keeps some resources allocated.

Do you close properly the allocated window, free the cursor, ... ?

neam
  • 894
  • 9
  • 19
  • I am indeed using Qt, can it create false positives? Thanks for pointing out the OpenGL part, that's what I was missing. Is there a way to pinpoint accurately at least what is not deallocated? The code base is rather large, and I have not written it so it feels a bit like looking for a needle in a haystack. – Leherenn Nov 18 '15 at 08:58
  • You can try to isolate the problem by creating an empty qt app (with only initialisation and de-initialisation) and see if it leaks. Another tool, `valgrind` (`memcheck`) could help you to see if its really a leak of if it is still reachable. But yes, I would not be surprised if Qt keeps some memory and never free it (not a leak though, but some kind of pool or objects created one time in the program life for some purpose) – neam Nov 18 '15 at 09:08
  • 1
    A quite interresting link on the issue: http://doc.qt.io/qtcreator/creator-analyzer.html and there are other SO questions about `Qt` and `valgrind` – neam Nov 18 '15 at 09:23