|
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.
--
|