Search code examples
c++gccmemory-leaksleak-sanitizer

Understanding LeakSanitizer outputs

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.

Solution

  • ==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, ... ?