Re: [Valgrind-users] Using Valgrind with my Own Memory Management

[Nicholas N. <nj...@ca...>]

On Mon, 12 May 2003, Seto wrote:

> Has anyone been using Valgrind successfully with his/her
> own memory management or maybe has some ideas on what
> should people do when using Valgrind with their own memory
> management, so Valgrind will report useful memory information?

It will still work, but give less information.  The validity checks will
be fine.  The addressability checks will be less accurate, because your
allocator might allocate superblocks and then dole out small blocks from
within that; so small-block-overruns probably wouldn't be found. Some
other errors you obviously won't get (eg. mismatched malloc/new/new[] vs.
free/delete/delete[], accessing blocks after free()ing them).  Memory leak
checking (--leak-check) also won't be any use as it's based around
recording malloc/new/new[] blocks.  Also, error locations will be less
accurate, as errors within your non-malloc'd blocks won't be identified as
such.

----

Hmm... some client requests could be useful here.  For example:

  VALGRIND_MALLOCLIKE_BLOCK(mallocname, addr, rz1, size, rz2)
  VALGRIND_FREELIKE_BLOCK(freename, addr, rz1, rz2)

The first would tell Valgrind that the block at 'addr' of size 'size' is a
malloc-like block and should be recorded as such, the second should be
obvious.  You could use it like this:

void* my_alloc(int size)
{
    void* p = <get memory block somehow>;
    VALGRIND_MALLOCLIKE_BLOCK("my_alloc", p, 0, size, 0);
    return p;
}

void* my_free(void* p)
{
    <free p's memory somehow>
    VALGRIND_FREELIKE_BLOCK("my_free", p, 0, 0)
}

By introducing a new alloc type 'AllocOther' to complement the existing
'AllocMalloc', 'AllocNew', 'AllocVecNew', error messages could be made to
say things like:

error blah blah
   at 0x...
   by 0x...
Address 0x12345678 is within a block of size 100 my_alloc'd
   at 0x...
   by 0x...

This would allow error checking to be almost as good as it is for malloc
et al (superblocks could be marked inaccessible at first with the
VALGRIND_MARK_NOACCESS request).  The only shortcomings would be:

1. redzones -- Valgrind's malloc pads heap blocks with redzones to help
   detect overruns and underruns;  the 'rz1' and 'rz2' args above would
   allow a custom allocator to use them if it could.  The rz1 and rz2 args
   would have to match in VALGRIND_MALLOCLIKE_BLOCK and
   VALGRIND_FREELIKE_BLOCK.

2. accesses to freed memory -- Valgrind's allocator deliberately postpones
   the reuse of freed blocks to help catch any accesses after their free.
   A custom allocator could also do this, although it wouldn't be
   necessary.

This seems quite neat and doable to me -- it would fit in fairly easily
with the heap-block-tracking Valgrind already has.  I'll put it on my "to
consider" list... if anyone else would find this useful, speak up, and
that will increase the likelihood of it being implemented.

N