Re: Dumper issue, revisited; invalid realloc/free

[Rich Felker]

On Wed, Feb 04, 2015 at 09:44:17PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 4 Feb 2015 14:37:32 -0500
> > From: Rich Felker <address@hidden>
> > Cc: address@hidden
> > 
> > > > 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.
> > 
> > As I suspected, this code is used only if you use gmalloc.c. It's not
> > used with system_malloc=yes, which is the case I'm concerned about.
> 
> No, you are mistaken.  The 'master' version of Emacs uses the system
> malloc on MS-Windows.  Perhaps you are looking at the 'emacs-24'
> branch, where indeed we use gmalloc.c and ralloc.c, with sbrk
> emulation in w32heap.c.  But that's not what I had in mind.

Ah, I wasn't aware there was significant new development in this area!
I'll take a look at master.

> > > Or that the libc memory allocation routines can gracefully handle
> > > these situations.
> > 
> > I would not consider that "graceful". If they detect that the pointer
> > passed to realloc or free is invalid, the only reasonable behavior is
> > to abort.
> 
> They could do exactly what you planned to do: ignore the 'free' part
> and only allocate a new block.

This behavior does not make sense in system malloc; it's only logical
if you know the erroneous call is a result of emacs' dumper. The usual
case when a data/bss pointer is passed to realloc or free is a serious
programming error or memory corruption and the responsible thing to do
when this is seen (if you bother to detect it) is to abort the program
before something worse happens.

Rich