[PATCH] D31978: Fix memory leaks in address sanitizer darwin tests

Francis Ricci via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 12 10:03:24 PDT 2017


fjricci added inline comments.


================
Comment at: test/asan/TestCases/Darwin/malloc_set_zone_name-mprotect.cc:52
+  // but it's leaked unless cleared
+  malloc_set_zone_name(zone, NULL);
+  malloc_destroy_zone(zone);
----------------
alekseyshl wrote:
> kubamracek wrote:
> > alekseyshl wrote:
> > > fjricci wrote:
> > > > fjricci wrote:
> > > > > alekseyshl wrote:
> > > > > > Who's holding (and leaking) the buffer?
> > > > > From looking at the only malloc_set_zone_name source I could find (https://opensource.apple.com/source/Libc/Libc-320.1.3/gen/malloc.c), it looks like libc itself is holding a copy, which it frees whenever the name is overwritten. For some reason, malloc_destroy_zone doesn't free that buffer (I assume it should).
> > > > Another alternative which would probably work would be calling 'free(malloc_get_zone_name(zone))`, but that seemed hackier.
> > > Looking at the code, it's not a leak. The zone name buffer is allocated within the zone itself, so destroying the zone effectively deallocates the name too.
> > This leaks because we have an interceptor for malloc_destroy_zone, which doesn't really destroy the zone, nor does it free the name (see sanitizer_malloc_mac.inc).  Could this be fixed in the interceptor instead?
> Right, what I meant to say, the actual malloc does not leak the name.
> 
> Fixing it in the interceptor sounds like a better idea.
Changing the interceptor to free the name does fix the leak, I'll pull that out into a separate patch.


https://reviews.llvm.org/D31978





More information about the llvm-commits mailing list