Dumper issue, revisited; invalid realloc/free

[Rich Felker <dalias@libc.org>]

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

(Note: there are a couple known bugs in the attached code.)

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.
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.

The simplest solution I can find is to make the affected free
functions (xrealloc, xfree, lisp_free, and lisp_align_free) check
whether their argument is in the range of data_start...initial_brk and
act as a nop (or in the case of xrealloc, allocate a new object
without freeing the old one) when this is the case. The check is
easily accomplished by saving initial_brk=sbrk(0) at startup (to be
lazy I did this with attribute((constructor)) but other approaches
might be preferred for an upstream fix. For xrealloc, since the old
size is not known, I simply estimate it as initial_brk-block. Copying
up to the min or this value and the new size should be safe, anyway.

Does this sound acceptable for upstream?

Rich