|
From: Sree H. T. <tot...@in...> - 2012-09-11 10:23:41
|
Hello,
I couldn't understand the following leak reported by Valgrind:
==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)
==26780==
==26780==
==26780== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:malloc
fun:make_request
fun:__check_pf
}
==26780== LEAK SUMMARY:
==26780== definitely lost: 0 bytes in 0 blocks
==26780== indirectly lost: 0 bytes in 0 blocks
==26780== possibly lost: 0 bytes in 0 blocks
==26780== still reachable: 304 bytes in 1 blocks
==26780== suppressed: 11,542 bytes in 156 blocks
==26780==
==26780== For counts of detected and suppressed errors, rerun with: -v
==26780== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
There is no file check_pf.c as part of my source code. It seems to be a
part of glibc. Does this mean that there is a leak in libc?
I'm using Valgrind-3.7.0 and libc 2.15.
Regards,
Sree Harsha
|
|
From: John R. <jr...@bi...> - 2012-09-11 18:15:40
|
> ==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?
> ==26780==
> ==26780==
> ==26780== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
> {
> <insert_a_suppression_name_here>
> Memcheck:Leak
> fun:malloc
> fun:make_request
> fun:__check_pf
> }
> ==26780== LEAK SUMMARY:
> ==26780== definitely lost: 0 bytes in 0 blocks
> ==26780== indirectly lost: 0 bytes in 0 blocks
> ==26780== possibly lost: 0 bytes in 0 blocks
> ==26780== still reachable: 304 bytes in 1 blocks
> ==26780== suppressed: 11,542 bytes in 156 blocks
> ==26780==
> ==26780== For counts of detected and suppressed errors, rerun with: -v
> ==26780== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> There is no file check_pf.c as part of my source code. It seems to be a
> part of glibc. Does this mean that there is a leak in libc?
__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.
--
|
|
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
|