memory leak in free()

Krassimir Slavchev krassi at bulinfo.net
Thu Jun 15 09:00:28 UTC 2006


Jason Evans wrote:
> 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@ 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.
>
Yes, this is on a 32 bit system.
After what time the kernel should free the unused space? If the interval 
between malloc()  and free() is
10 seconds for example the 'SIZE' and 'RES' shown by top are increasing.
Also if only one big buffer is used the problem does not exist.
> 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.
>
I can't decrease the data segment because I load some files ~4Mb each in 
memory buffers and
then stream the buffers cyclic via IO port as fast as possible. However, 
I use 5.4-STABLE in production.
> Incidentally, this isn't an issue on 64-bit systems, since only mmap() 
> is used to request memory from the kernel.
>
> Jason
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"
>

Best Regards



More information about the freebsd-current mailing list