Re: Removal of unexec support from glibc malloc

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sat, 23 Jan 2016 10:29:33 -0500
> 
> > AFAICS, it happens due to the following:
> >   . We call regex.c functions, which reuse an allocated buffer,
> >     extending it (via realloc) as needed; that buffer gets frozen with
> >     malloc arena used during dumping
> >   . We delete the terminal frame used by temacs and free its resources
> >   . Not 100% sure, but I think we also release/reallocate some
> >     font-related stuff
> > It's easy to catch all those cases by setting a breakpoint on realloc
> > and free during startup.
> 
> I guess that's what happens in practice, but I'd be surprised if there
> aren't more cases that can happen in theory.

Right now, anything can happen in theory, because we don't generally
write specialized code for temacs, we use the "normal" code, both in
Lisp and in C.  The only significant difference is the use of 'pure'.

> I'm thinking of memory areas allocated for Elisp data which will
> *usually* stay live during the lifetime of Emacs, but which could
> become free if we do things like re-define some core datastructure
> (e.g. I'm thinking of things like (setq global-map (copy-keymap
> global-map)).

I don't understand the last part of this at all.

AFAIU, the problem is not with Lisp data, the problem is with memory
allocations on the C level that are not on behalf of Lisp data.  We
need to find a way of doing that without relying on that data be
fee'able after dumping.