|
From: Sree H. T. <tot...@in...> - 2012-09-11 21:28:16
|
On 09/11/2012 09:25 PM, Sree Harsha Totakura wrote:
> On 09/11/2012 08:16 PM, John Reiser wrote:
>>> ==26780== 304 bytes in 1 blocks are still reachable in loss record 51 of 59
>>> ==26780== at 0x402CE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>>> ==26780== by 0x41DD1C5: make_request (check_pf.c:249)
>>> ==26780== by 0x41DD63E: __check_pf (check_pf.c:342)
>>
>> That traceback seems to be short: only 3 subroutines. By default the limit is 12.
>> Did you set --num-callers=<number>, or are threads involved?
No, I didn't set --num-callers and there were no threads involved.
>> __check_pf is a function in glibc. The leak in question is the result structure
>> from subroutine make_request:
>>
>> ----- glibc-2.15/sysdeps/unix/sysv/linux/check_pf.c
>> struct cached_data *result;
>> if (seen_ipv6 && in6ailist != NULL)
>> {
>> result = malloc (sizeof (*result)
>> + in6ailistlen * sizeof (struct in6addrinfo));
>> -----
>>
>> which __check_pf uses to maintain a 1-item cache. While it is technically
>> a leak (it could have been free()d immediately after the last use, except
>> determining that instant is difficult), the size is bounded and small,
>> and in general programs that call __check_pf more than once will tend
>> to perform faster because of the cache.
>> Therefore probably you don't want to insist that this leak go away.
That's a clear explanation. Thank you.
--
Sree Harsha
|