Re: [Valgrind-developers] Bug 73655 fix

[Robert W. <rj...@du...>]

> So if a program has its own version of new or new[], Valgrind doesn't know
> anything about them, and any heap blocks allocated with them won't be
> checked as normal?

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.

> Is it possible to have a custom 'new' but a non-custom
> 'delete'?  That could cause false free errors?

Yes, but I don't think they'd be false errors.  If your custom operator
new() uses malloc, then your custom operator delete() should use
free...  If there is not custom operator delete(), then you're doing
something wrong and Valgrind would be correct in pointing that out.

Regards,
 Robert.