Re: memory leak in free()

John Baldwin wrote:
> On Wednesday 14 June 2006 04:07, Krassimir Slavchev wrote:
> 
>>Hello,
>>
>>This simple code demonstrates the problem:
>>
>>int main ()
>>{
>>    char* buffer1;
>>    char* buffer2;
>>    int size = 2*1024*1024 + 1;
>>
>>for(;;) {
>>        buffer1 = (char *) malloc(size);
>>        buffer2 = (char *) malloc(size);
>>
>>        free(buffer1);
>>        free(buffer2);
>> }
>>}
>>
>>The second free() does not free allocated memory if size >2Mb.
>>
>>On 6.1-STABLE all is OK.
> 
> 
> This is probably an issue with jemalloc, I've cc'd jasone_at_ who wrote the
> new malloc() in HEAD.
> 

This is on a 32-bit system, right?  If so, what's happening is that the 
brk-managed space (data segment) is being fragmented, such that the 
address space isn't returned to the OS.  However, this is not really a 
memory leak, since madvise() is called in order to let the kernel know 
that the unused space need not be swapped out.

I was reluctant to allow allocations > 1MB to be carved from brk because 
I knew this could happen, but people complained about it, so I added the 
feature.  In practice, I think the current implementation makes the 
right tradeoff, but I have no strong feelings on the matter.

If this is causing you particular problems for some application, a 
simple way to work around it is to decrease the data segment size for 
the application.  That will cause most/all allocations to be carved from 
memory via mmap() instead.

Incidentally, this isn't an issue on 64-bit systems, since only mmap() 
is used to request memory from the kernel.

Jason