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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
