On Dec 23, 2014, at 12:22 AM, cee1 <fykcee1@gmail.com> wrote:

Hi all,

I'm interesting to the internal of malloc in OS X and learning some code snippets of it, and I find it seems forget to free page_bitarray in nano_try_madvise() (http://www.opensource.apple.com/source/libmalloc/libmalloc-53.1.1/src/nano_m..., line 1395):

""" bitarray_t slot_bitarray = bitarray_create(log_size); bitarray_t page_bitarray = bitarray_create(log_page_count);

if (!slot_bitarray) { /******* Shouldn't we free(page_bitarray) here？*******/ return bytes_toward_goal; }

if (!page_bitarray) { free(slot_bitarray); return bytes_toward_goal; } """

Your analysis looks correct to me. You should file a bug report. In practice this should not be a serious problem. A process that fails to allocate a bit array is almost certainly going to die very soon due to other out-of-memory failures.

BTW, in segregated_band_grow(), does it miss an unmap call if return another vm area that's not what asked for?

""" kern_return_t kr = mach_vm_map(mach_task_self(), &vm_addr, BAND_SIZE, 0, VM_MAKE_TAG(VM_MEMORY_MALLOC_NANO), MEMORY_OBJECT_NULL, 0, FALSE, VM_PROT_DEFAULT, VM_PROT_ALL, VM_INHERIT_DEFAULT);

void *q = (uintptr_t)vm_addr; if (kr || q != (void *)(p & ~((uintptr_t)(BAND_SIZE - 1)))) // Must get exactly what we asked for return FALSE;

"""

mach_vm_map() with that set of parameters is not allowed to return an address that is not the requested address. That part of the check will never fail unless there is a bug in mach_vm_map(). It would make sense to rearrange or annotate the code to clarify the check, but it should never result in a memory leak. -- Greg Parker gparker@apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com