|
From: Nicholas N. <nj...@ca...> - 2004-04-14 09:07:29
|
On Tue, 13 Apr 2004, Robert Walsh wrote: > Well, most of these new and deletes are going to be doing some sort of > allocation and freeing at the end of the day. I can see several > scenarios: > > * custom allocator doesn't actually allocate anything. > * custom allocator allocates memory by doing a call to the glibc > version of the allocator after looking up it's address using > dlsym(RTLD_NEXT, ...). > * custom allocator allocates memory by doing a call to malloc or > some other existing allocator. > * custom allocator allocates memory using some custom mechanism, > such as a memory pool. > > In the first scenario, nothing happens. That's just weird anyway, and I > can't imagine it happening very often, but you never know. In any case, > nothing is allocated and life goes on. Valgrind won't mind at all. > > In the second scenario, the glibc allocator is eventually called, but > that call gets intercepted by Valgrind and treated as normal. This is > probably most often used for error-checking malloc wrappers and the > like. > > In the third scenario, operator new or whatever calls malloc or > something like that. This too will get intercepted by Valgrind as a > regular malloc. This is what the new_override.cpp test does. > > In the fourth scenario, everything is up in the air, but I don't see why > Valgrind should care, as long as the underlying memory allocation > mechanism is intercepted. > > If I'm forgetting anything, let me know. All sounds good to me. With the fourth scenario, they would have to use client requests as with any other custom allocator. Thanks for clearing this up for me. N |