GNU bug report logs - #22086
25.1.50; [PATCH] Integrate the musl hybrid malloc patch for elf systems

Previous Next

Full log

Message #47 received at 22086 <at> debbugs.gnu.org (full text, mbox):

From: Rich Felker <dalias <at> aerifal.cx>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Wolfgang Jenkner <wjenkner <at> inode.at>, 22086 <at> debbugs.gnu.org
Subject: Re: bug#22086: 25.1.50; [PATCH] Integrate the musl hybrid malloc
 patch for elf systems
Date: Sun, 20 Dec 2015 21:51:17 -0500

On Sun, Dec 20, 2015 at 06:37:35PM -0800, Paul Eggert wrote:
> Rich Felker wrote:
> >I don't object to this change if you can reliably ensure that nothing
> >in the pre-dump emacs will call malloc.
> 
> We can't reliably ensure that, I'm afraid, as Emacs might call some
> library function that in turn calls malloc. It might be a 3rd-party
> library that Emacs has no control over.
> 
> Why can't pre-dump emacs call malloc? Is it a performance thing or a
> correctness thing? If a performance thing it shouldn't be much of a
> problem, as we can arrange for Emacs to never directly call malloc,
> and that should be the vast majority of the calls.

It's a correctness thing. The dumper can only dump the brk heap that's
contiguous with .data/.bss (and even that's not contiguous on modern
hardened kernels). This is why fake brk in static storage has to be
used by hybrid malloc. But even if the system malloc did guarantee
contiguity, it's not valid to keep using heap data structures from one
instance of the allocator with a new instance of the allocator, and
there are different failure modes for static and dynamic linking, but
both are bad.

In practice it _might_ work to varying degrees, but it's fundamentally
fragile and wrong.

Rich

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.