| Summary: | MEMPOOL_FREE not reflected in heap summary | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | theseaisinhere |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | eugeny.grishul |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | a patch | ||
|
Description
theseaisinhere
2010-04-04 23:57:29 UTC
Created attachment 42491 [details]
a patch
Here is a patch that fixes the issue for me. Be advised that my use of MEMPOOL_TRIM is very simplistic (it's used to free the entire mempool at once), so this may not test the various code paths. I incremented cmalloc_n_frees under TRIM and FREE where it seemed appropriate.
It also reproduced on latest valgrind-3.6.1 on Fedora 15 with gcc 4.6.0
Use following program to test incorrect 'mempool_free' client request handling:
#include <valgrind/valgrind.h>
int main( int argc, char** argv, char **envp ) {
auto pool = new long long[100];
VALGRIND_CREATE_MEMPOOL( pool, 0, false );
VALGRIND_MEMPOOL_ALLOC( pool, pool, 8 );
VALGRIND_MEMPOOL_FREE( pool, pool );
VALGRIND_DESTROY_MEMPOOL( pool );
delete[] pool;
return 0;
}
// =======================================================
...
==24739== create_mempool(0x402e028, 0, 0)
...
==24739== mempool_alloc(0x402e028, 0x402e028, 8)
...
==24739== mempool_free(0x402e028, 0x402e028) freed chunk of 8 bytes
...
==24739== destroy_mempool(0x402e028)
...
==24739== total heap usage: 2 allocs, 1 frees, 808 bytes allocated
|