This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Overriding malloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 01 Jul 2014 11:10:44 +0200
- Subject: Re: Overriding malloc
- Authentication-results: sourceware.org; auth=none
- References: <53B27135 dot 4040308 at redhat dot com> <CANu=Dmjn0bsjj71=kit=gyZgm-354fYY861YjnPcmYT=+rMSDw at mail dot gmail dot com>
On 07/01/2014 10:56 AM, Will Newton wrote:
On 1 July 2014 09:28, Florian Weimer <fweimer@redhat.com> 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.
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.
Are you referring to the assert in nis/nss_nis/nis-netgrp.c?
Yes, indeed. I'm somewhat surprised there aren't any other callers left.
IMO malloc_usable_size should not be called from within glibc because
it is almost always a sign of bad code.
It could help to avoid the common case of bad exponential resizing
behavior. Allocating power-of-two buffer sizes tends to waste a lot of
memory. But that's not relevant for glibc, I admit.
> A good subset of the allocator
functions to require to be overridden would be the union of C90, C11
and POSIX:
Should we put this into the manual?
--
Florian Weimer / Red Hat Product Security