|
From: Jason E. <ja...@ca...> - 2005-05-06 15:18:54
|
On Thu, May 05, 2005 at 11:06:03PM -0700, Jeremy Fitzhardinge wrote:
> Jason Evans wrote:
>
> >========================================================================
> >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
> >@@ -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.
> >
> >
> 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.
If I understand correctly, this is bad (overlapping):
[------]
[-------]
And this is bad (nested):
[----------]
[----]
But this is the scenario that is causing me trouble (adjacent):
[------I------]
The lc_shadows assertion requires there to be a gap of at least one byte
between allocations; merely being non-overlapping isn't good enough to
avoid triggering the assertion:
[------] [------]
Is it in fact important to valgrind that there be gaps between allocations?
Thanks,
Jason
P.S. As for my malloc implementation, it does use mmap(), and it does take
care to avoid ever telling valgrind that allocations overlap/nest
(which BTW made adding the valgrind macro calls very tricky). It's a
complete malloc replacement, rather than an allocator that builds on
top of the system malloc.
|