Re: Dumper issue, revisited; invalid realloc/free

[Rich Felker <dalias@libc.org>]

On Wed, Feb 04, 2015 at 08:31:47PM -0500, Rich Felker wrote:
> On Wed, Feb 04, 2015 at 03:34:40PM -0500, Ken Brown wrote:
> > On 2/4/2015 2:26 PM, Eli Zaretskii wrote:
> > >>Date: Wed, 4 Feb 2015 14:13:05 -0500
> > >>From: Rich Felker <dalias@libc.org>
> > >>Cc: emacs-devel@gnu.org
> > >>
> > >>>Yes.  Several platforms (Cygwin and MinGW on MS-Windows) already do
> > >>>exactly that.
> > >>
> > >>Where is the code that does this? I don't see it in alloc.c.
> > >
> > >The Cygwin code is in sheap.c, the MinGW code is in w32heap.c.
> > >
> > >>Is it only used when system_malloc=no? The case where it's really
> > >>needed is for system_malloc=yes...
> > >
> > >MinGW uses that with system malloc.  Not sure about Cygwin.
> > 
> > Cygwin (in the master branch) uses gmalloc.c before dumping and the
> > system malloc after dumping.  See the code in gmalloc.c involving
> > HYBRID_MALLOC.
> 
> Interesting. This is new code I hadn't seen yet (seemingly based on
> the conversations last summer) and looks very promising. But I'm
> curious -- how do you prevent pointers obtained from the
> before-dumping gmalloc from getting passed to the system malloc's
> free? If we can solve this I think we have a clean, robust way to get
> GNU Emacs building correctly on musl without hacks.

After reading the source, I see -- there's a simple range checking
macro. Simply removing the #ifdef CYGWIN around all the relevant code
seems to make it work with no further hackery, which is very
promising, but with current git master I'm hitting lots of lisp
failures later in the build process, seemingly due to failure of
autoloads to work, although some of the failures don't even seem to be
mentioned in autoload.el. Is this kind of failure expected working
with bleeding edge (if so I'll seek support somewhere more
appropriate), or does it sound like something went wrong in dumping?

Rich