|
From: Jason E. <ja...@ca...> - 2005-05-02 23:30:28
|
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.
The lc_shadows assertion fails because it assumes that allocations cannot
be directly adjacent.
Thanks,
Jason
P.S. As an aside, I must say that I am very impressed at how gracefully
valgrind deals with the application replacing malloc. My initial
assumption was that it wouldn't work at all.
|