|
From: Jeremy F. <je...@go...> - 2005-03-01 00:49:49
|
Nicholas Nethercote wrote:
> I'd be happy for VALGRIND_MAKE_* to not create its own blocks, I don't
> think we'd lose much with that. In fact, I vaguely recall that the
> memory address identification code has to do some awkward things to
> deal with those special blocks.
Well, it checks to see if the address is within one. Do you think we
can do without them altogether, or there should be a client call to
create them? I've never used them, but I can see a use, particularly if
you can associate a descriptive string with them which is displayed when
hit.
> As for MALLOCLIKE/FREELIKE, they're good enough for simple custom
> allocators. See memcheck/tests/custom_alloc.c for an example.
custom_alloc.c is a little bit *too* simplistic, since it doesn't
implement free(), or any kind of freelist, or any block recycling. Its
the freelist management which bites you.
> I'm not surprised that they causes problems if you use it with
> malloc(); that's not something I'd considered, because I didn't think
> anyone would build a custom allocator on top of malloc(). There may
> certainly be room for improvement.
I ran into it by accident while trying to come up with a minimal but
slightly more complete replacement for custom_alloc.c. At the very
least the leak checker shouldn't assert over them. Should it simply
ignore AllocCustom chunks if they're embedded within another chunk?
J
|