libnuma valgrind errors

libnuma valgrind errors

[Trammell Hudson]

When running a trivial program linked with -lnuma under valgrind I get
errors that numa_bitmask_alloc() has been called and not freed the memory. 
This is on Ubuntu 9.04, with libnuma 2.0.2 on x86-64.

Test program:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    void * buf = malloc(1024);
    printf("buf=%p\n", buf);
    free(buf);
    return 0;
}


Output:
uname -a
Linux dev 2.6.30.4 #4 SMP PREEMPT Thu Jan 14 20:16:13 GMT 2010 x86_64
GNU/Linux
gcc -O3 -W -Wall ./test-vg.c  -lnuma
valgrind --leak-check=full --show-reachable=yes  a.out
==5385== Memcheck, a memory error detector
==5385== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==5385== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==5385== Command: a.out
==5385== 
buf=0x53a9c80
==5385== 
==5385== HEAP SUMMARY:
==5385==     in use at exit: 72 bytes in 6 blocks
==5385==   total heap usage: 16 allocs, 10 frees, 15,408 bytes allocated
==5385== 
==5385== 8 bytes in 1 blocks are still reachable in loss record 1 of 6
==5385==    at 0x4C2549B: calloc (vg_replace_malloc.c:418)
==5385==    by 0x4E2F3C4: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E3075A: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== 8 bytes in 1 blocks are still reachable in loss record 2 of 6
==5385==    at 0x4C2549B: calloc (vg_replace_malloc.c:418)
==5385==    by 0x4E2F3C4: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E30769: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== 8 bytes in 1 blocks are still reachable in loss record 3 of 6
==5385==    at 0x4C2549B: calloc (vg_replace_malloc.c:418)
==5385==    by 0x4E2F3C4: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E30778: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== 16 bytes in 1 blocks are still reachable in loss record 4 of 6
==5385==    at 0x4C26177: malloc (vg_replace_malloc.c:195)
==5385==    by 0x4E2F3A5: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E3075A: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== 16 bytes in 1 blocks are still reachable in loss record 5 of 6
==5385==    at 0x4C26177: malloc (vg_replace_malloc.c:195)
==5385==    by 0x4E2F3A5: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E30769: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== 16 bytes in 1 blocks are still reachable in loss record 6 of 6
==5385==    at 0x4C26177: malloc (vg_replace_malloc.c:195)
==5385==    by 0x4E2F3A5: numa_bitmask_alloc (in /usr/lib/libnuma.so.1)
==5385==    by 0x4E30778: ??? (in /usr/lib/libnuma.so.1)
==5385==    by 0x400EC6F: ??? (in /lib/ld-2.9.so.FCS)
==5385==    by 0x4000AC9: ??? (in /lib/ld-2.9.so.FCS)
==5385== 
==5385== LEAK SUMMARY:
==5385==    definitely lost: 0 bytes in 0 blocks
==5385==    indirectly lost: 0 bytes in 0 blocks
==5385==      possibly lost: 0 bytes in 0 blocks
==5385==    still reachable: 72 bytes in 6 blocks
==5385==         suppressed: 0 bytes in 0 blocks
==5385== 
==5385== For counts of detected and suppressed errors, rerun with: -v
==5385== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)

Re: libnuma valgrind errors

[Andi Kleen]

On Fri, Jul 02, 2010 at 11:55:09AM -0600, Trammell Hudson wrote:
> When running a trivial program linked with -lnuma under valgrind I get
> errors that numa_bitmask_alloc() has been called and not freed the memory. 
> This is on Ubuntu 9.04, with libnuma 2.0.2 on x86-64.

This is a false positive -- the values are essentially globals that never
go away and it's not a bug. If you don't want to see you would need to use 
a suppression file.

-Andi