|
From: Jeremy F. <je...@go...> - 2005-05-06 09:11:59
|
Jason Evans wrote:
>I've run into two problems with valgrind that the following patch works
>around:
>
>========================================================================
>diff -ru valgrind-2.4.0.orig/memcheck/mac_leakcheck.c valgrind-2.4.0/memcheck/mac_leakcheck.c
>--- valgrind-2.4.0.orig/memcheck/mac_leakcheck.c 2005-03-10 22:28:15.000000000 -0800
>+++ valgrind-2.4.0/memcheck/mac_leakcheck.c 2005-05-02 16:16:22.659375486 -0700
>@@ -431,7 +431,6 @@
> lc_do_leakcheck(i);
>
> sk_assert(lc_markstack_top == -1);
>- sk_assert(lc_markstack[i].state == IndirectLeak);
>
> lc_markstack[i].state = Unreached; /* Return to unreached state,
> to indicate its a clique
>@@ -589,7 +588,7 @@
> /* Sanity check -- make sure they don't overlap */
> for (i = 0; i < lc_n_shadows-1; i++) {
> sk_assert( lc_shadows[i]->data + lc_shadows[i]->size
>- < lc_shadows[i+1]->data );
>+ <= lc_shadows[i+1]->data );
> }
>
> if (lc_n_shadows == 0) {
>========================================================================
>
>I ran into these problems when adding VALGRIND_{MALLOC,FREE}LIKE_BLOCK()
>calls to a malloc library that I implemented. The malloc library
>completely replaces all malloc(3)-related APIs. In order to avoid UMRs, I
>have to tell valgrind that the separators between regions are allocated,
>and the same applies to data structures that are stored in cached free
>regions.
>
>I don't understand why the IndirectLeak assertion fails for my code, but
>I'm guessing that it's an assertion that is only valid for valgrind's own
>malloc replacement.
>
>
It's a bit more subtle than that. Valgrind has an assumption that
malloc blocks are not nested, so you can't have a user-defined allocated
block within a malloced block. The workaround is to use mmap() to
allocate memory for your malloc replacement.
J
|