emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dumper issue, revisited; invalid realloc/free


From: Rich Felker
Subject: Re: Dumper issue, revisited; invalid realloc/free
Date: Wed, 4 Feb 2015 20:31:47 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden>
> >>Cc: address@hidden
> >>
> >>>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.

Rich



reply via email to

[Prev in Thread] Current Thread [Next in Thread]