libasan detects leaks about libs-base HOT 5 OPEN

Maybe I'm missing something, but libraries create resources which are expected to last until the program exits;
Is there a reason to think that libasan (I'm not familiar with that) is reporting anything other than those (ie false positives)?

from libs-base.

Does libasan have a way to produce a long enough stack trace to tell you where to look to see why the memory was allocated?

from libs-base.

Hi John,

thank you for your efforts. I did not know about this AddressSanitizer (libasan) but previously I used to run Valgrind again GNUstep applications to get similar information about our memory management.
First off, the results you found are in their current form not helpful, with a stack depth of two we only see that some objects where allocated and never freed, but cannot see where they were allocated nor which kind of objects these are.
Next, as Richard already pointed out, this could be natural behaviour for the effected libraries. I seem to remember that Richard even added some setting for libbase, that would allow these objects to register for cleanup at exit, but this needs to be enabled and is also not used in all places. Normally analysis tools come preconfigured with a list of such allocations that should be ignored in specific libraries. As GNUstep is a rather small project we cannot expect that such configurations for our libraries get shipped automatically. What you could do is use the result of your test and somehow create such an ignore list with it (no idea how this is done with libasan) and then take an actual GNUstep application and run libasan with this ignore list. The results from that analysis would be more useful.
The actual interesting cases are when there is a memory leak during that run of an application that accumulates never time. A few static allocated objects that a library won't clean up at exit may be ignored. The time spend to clean up is just not worth it.
When I ran my analysis with Valgrind the results for the GNUstep libraries where quite OK, of course after fixing some existing memory issues :-)

from libs-base.

Thanks for saying all the stuff I ought to have said Fred.
You are surely right to point out that the 'cleanup at exit' in the base library is woefully incomplete; I basically gave up part way through implementing it because nobody really seemed interested in the idea of ensuring long term data structures could be destroyed at exit to avoid confusing leak checkers (also because it adds code complexity for no functional gain).

from libs-base.

This can also come from libobjc2 if using GCC and legacy (assuming you are using libobjc2 and not gcc-objc):

If you're compiling with GCC (which I strongly recommend against), then it will emit the ancient GCC Objective-C ABI where a large number of features will not work. We do an upgrade pass on loading, which constructs the structures for the new ABI with heap memory for all loaded classes. This will probably show up as leaked, because we never free it (it is expected to be present for the lifetime of the program and there is no benefit from calling free a bunch of times before exit).

If you compile with clang and -fobjc-runtime=gnustep-2.0 (or 2.2 if you're using trunk), then you should not see these copies.

Originally posted by @davidchisnall in gnustep/libobjc2#270 (comment)

from libs-base.