Date: Thu, 15 Jun 2006 12:00:02 +0300 From: Krassimir Slavchev <krassi@bulinfo.net> To: Jason Evans <jasone@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: memory leak in free() Message-ID: <44912192.2030806@bulinfo.net> In-Reply-To: <449048C7.6090109@FreeBSD.org> References: <448FC3AF.9060606@bulinfo.net> <200606141023.51185.jhb@freebsd.org> <449048C7.6090109@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe@freebsd.org"
>
Best Regards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44912192.2030806>