Re: Overriding malloc

[Rich Felker <dalias at libc dot org>]

On Tue, Jul 01, 2014 at 10:28:37AM +0200, Florian Weimer wrote:
> We need to support overriding malloc through LD_PRELOAD and other
> forms of symbol interposition.  Once you override malloc, you also
> have to override free, realloc and calloc at least.
> 
> If the application (or one of its libraries) uses posix_memalign
> etc., these have to be overridden as well.  Same for the
> malloc_usable_size.

Don't forget aligned_alloc (C11). This is one that's likely to be
overlooked in any malloc replacement since it's so new. And
aligned_alloc can't just call posix_memalign or memalign as its
implementation to work around the problem, because the latter are,
with respect to C11, in the namespace reserved for the application.

> The question is if overriding those should is required even if the
> application does not call those fringe malloc-related functions,
> i.e. if glibc should behave as if it never calls them if malloc has
> been overridden.
> 
> If yes, we should likely remove the remaining call to
> malloc_usable_size from the code base.

Even if glibc behaves as if it does not call these "extra" functions,
it's very hard for an application (to guarantee that none of the
third-party libraries it links to does so).

If you really want to "officially" support overriding malloc rather
than having it be a nasty hack that "probably works", I think there
needs to be some dynamic-linking magic that checks that a malloc
replacement overrides ALL malloc-system functions together, and to
either issue an error or suppress all the definitions if any are
missing.

Rich