|
From: Björn F. <bj...@fa...> - 2011-07-19 10:31:10
|
When attempting to use a mempool, I get a number of odd reports at exit (not
the ones mentioned in the FAQ about old glibc.) I presume I am missing
something. The following very small program shows the problem I have:
#include <valgrind/valgrind.h>
#include <stdio.h>
static char buffer[1024];
int main(void)
{
printf("buffer=%p\n", buffer);
VALGRIND_CREATE_MEMPOOL(buffer, sizeof(buffer), 0);
VALGRIND_MEMPOOL_ALLOC(buffer, buffer + 8, 10);
/* VALGRIND_MEMPOOL_FREE(buffer, buffer + 8); */
VALGRIND_DESTROY_MEMPOOL(buffer);
return 0;
}
When run, I get the following result:
==9727== Memcheck, a memory error detector
==9727== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==9727== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==9727== Command: ./a.out
==9727==
buffer=0x601040
==9727== Invalid read of size 8
==9727== at 0x400E213: _dl_fini (in /lib64/ld-2.12.2.so)
==9727== by 0x4E62034: __run_exit_handlers (in /lib64/libc-2.12.2.so)
==9727== by 0x4E62084: exit (in /lib64/libc-2.12.2.so)
==9727== by 0x4E4BD33: (below main) (in /lib64/libc-2.12.2.so)
==9727== Address 0x600e68 is not stack'd, malloc'd or (recently) free'd
==9727==
==9727== Invalid read of size 1
==9727== at 0x4004A9: ??? (in /tmp/a.out)
==9727== by 0x4009E0: ??? (in /tmp/a.out)
==9727== by 0x4E62034: __run_exit_handlers (in /lib64/libc-2.12.2.so)
==9727== by 0x4E62084: exit (in /lib64/libc-2.12.2.so)
==9727== by 0x4E4BD33: (below main) (in /lib64/libc-2.12.2.so)
==9727== Address 0x601020 is in the BSS segment of /tmp/a.out
==9727==
==9727== Invalid read of size 8
==9727== at 0x4004B7: ??? (in /tmp/a.out)
==9727== by 0x4009E0: ??? (in /tmp/a.out)
==9727== by 0x4E62034: __run_exit_handlers (in /lib64/libc-2.12.2.so)
==9727== by 0x4E62084: exit (in /lib64/libc-2.12.2.so)
==9727== by 0x4E4BD33: (below main) (in /lib64/libc-2.12.2.so)
==9727== Address 0x601028 is in the BSS segment of /tmp/a.out
==9727==
==9727== Invalid write of size 1
==9727== at 0x4004F6: ??? (in /tmp/a.out)
==9727== by 0x4009E0: ??? (in /tmp/a.out)
==9727== by 0x4E62034: __run_exit_handlers (in /lib64/libc-2.12.2.so)
==9727== by 0x4E62084: exit (in /lib64/libc-2.12.2.so)
==9727== by 0x4E4BD33: (below main) (in /lib64/libc-2.12.2.so)
==9727== Address 0x601020 is in the BSS segment of /tmp/a.out
==9727==
==9727==
==9727== HEAP SUMMARY:
==9727== in use at exit: 0 bytes in 0 blocks
==9727== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==9727==
==9727== All heap blocks were freed -- no leaks are possible
==9727==
==9727== For counts of detected and suppressed errors, rerun with: -v
==9727== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 12 from 8)
Commenting out VALGRIND_DESTROY_MEMPOOL(buffer) makes all errors disappear.
What am I missing here?
_
/Bjorn
|
|
From: Björn F. <bj...@fa...> - 2011-07-19 10:27:41
|
On Tuesday 19 July 2011 11.15.53 you wrote:
> When attempting to use a mempool, I get a number of odd reports at exit (not
> the ones mentioned in the FAQ about old glibc.) I presume I am missing
> something. The following very small program shows the problem I have:
For what it's worth, changing the program to get the buffer from sbrk()
instead sort of solves the problem. However, I'd rather not resort to sbrk()
in my real program.
#include <valgrind/valgrind.h>
#include <stdio.h>
#include <unistd.h>
int main(void)
{
char* buffer = (char*)sbrk(4096);
printf("buffer=%p\n", buffer);
VALGRIND_CREATE_MEMPOOL(buffer, sizeof(buffer), 0);
VALGRIND_MEMPOOL_ALLOC(buffer, buffer + 8, 10);
VALGRIND_MEMPOOL_FREE(buffer, buffer + 8);
VALGRIND_DESTROY_MEMPOOL(buffer);
return 0;
}
This now gives the report:
==9993== Memcheck, a memory error detector
==9993== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==9993== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==9993== Command: ./a.out
==9993==
buffer=0x4220000
==9993==
==9993== HEAP SUMMARY:
==9993== in use at exit: 0 bytes in 0 blocks
==9993== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==9993==
==9993== All heap blocks were freed -- no leaks are possible
==9993==
==9993== For counts of detected and suppressed errors, rerun with: -v
==9993== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
Unfortunately the heap summary is confusing. 0 frees? It looks like
VALGRIND_MEMPOOL_FREE() isn't counted. Commenting out that line gives the
exact same report, so something is a bit odd here.
_
/Bjorn
|