Re: Dumper issue, revisited; invalid realloc/free

[Eli Zaretskii]

> Date: Wed, 4 Feb 2015 12:57:09 -0500
> From: Rich Felker <address@hidden>
> 
> Last summer I started a thread about the ever-recurring dumper
> portability problem and how it was blocking use of emacs on systems
> based on musl libc. Recently I've been working with several people
> interested in getting emacs working on Alpine Linux and musl-based
> Gentoo, and I made some progress working around the issue:
> 
> http://www.openwall.com/lists/musl/2015/02/03/1

I suggest that you take a look at src/w32heap.c on Emacs's master
branch.  There' you will see a simple solution of a very similar (if
not identical) problem we have on MS-Windows.  It even includes a
simple handling of large allocations.

The only disadvantage of this scheme is that it wastes space in the
final binary, because the space reserved for the build-time
allocations needs to be large enough to support the building of
bootstrap-emacs, which is built before the Lisp files are compiled,
and thus needs roughly twice the space -- which is then wasted in the
next binary the build produces.  It would be nice to solve this at
some point, but it's not a catastrophe.

> However, on further examination, the workaround I did is insufficient.
> >From what I can tell, emacs is making an additional assumption on
> malloc: not only that malloc results will be contiguous with
> data/bss/brk so they can be dumped, but also that calling free() or
> realloc() on these objects in the new process after dumping is valid.

Either that, or realloc/free are never called on the objects allocated
before dumping.  On some platforms, the second assumption actually
holds.

> IMO this is utter nonsense, even with glibc or other widely-used
> systems. It imposes an assumption that the heap structures in the
> malloc version used at dump time match the heap structures in the
> malloc version used at runtime, and that the runtime malloc is not
> doing any sanity checks to catch and abort when a pointer into .data
> is passed to realloc/free.

Or that the libc memory allocation routines can gracefully handle
these situations.