This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The direction of malloc?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Will Newton <will dot newton at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andreas Jaeger <aj at suse dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Tue, 17 Dec 2013 12:01:32 +0100
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <CANu=Dmi32gwk-hQ3dDbj0d4_gs3FWqt02+NmveXH1p03Vm+Mfg at mail dot gmail dot com> <20131210111031 dot GH5048 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1312101654500 dot 15324 at digraph dot polyomino dot org dot uk> <CANu=Dmi5mr9z4P99LDB+8q6_1XcNraeofyScgFdwqOhZMBTTGQ at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1312101801170 dot 15324 at digraph dot polyomino dot org dot uk> <20131216214607 dot 1D6D07442E at topped-with-meat dot com>
On Mon, Dec 16, 2013 at 01:46:07PM -0800, Roland McGrath wrote:
> > The main purpose of malloc_get_state / malloc_set_state is for use by
> > emacs. If emacs adopted a better approach I'd happily deprecate them -
> > turn them into compat symbols - but you still need to support them
> > indefinitely with existing emacs binaries, as a matter of binary
> > compatibility. (Support could mean such binaries - binaries using the
> > malloc_set_state compat symbol - use a different copy of malloc in libc
> > from what all other binaries use, if necessary.)
>
> (I believe I've mentioned this before when discussing the ppc32 ABI
> situation.) I'm pretty sure that the way Emacs uses malloc before dumping
> is such that there's no significant amount of allocation done then (if any)
> that will ever be freed later. So for ABI compatibility it is probably
> sufficient to have a malloc_set_state call from an old binary result in the
> allocations made up to that point becoming unfreeable. For correctness,
> free in the new library would have to identify the given block as being
> from the old regime and not do anything bad. (Conceivably this could even
> be done just with a compat symbol version for free, though probably there
> are ways things will go wrong if the current-version free does bad things
> when given a pointer from the old-version allocator.) But it doesn't need
> to be able to actually do anything worthwhile, like recover that memory for
> future use, return it to the system, or ensure a double-free is detected.
Thanks, this simplifies a situation considerably. If we also a do not
extract free space then we only need to detect old-style pointers.
If a new implementation uses sentinel then I could do this with zero
performance impact for programs that do not use malloc_set_state. It
suffices to place odd sentinels where prev_size used to be, unless there is
corruption new-style pointers have this odd but a old style ones have that even.
You need this to support realloc as you need to know old size.