[Top][All Lists]

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

Re: Removal of unexec support from glibc malloc

From: Eli Zaretskii
Subject: Re: Removal of unexec support from glibc malloc
Date: Sat, 23 Jan 2016 17:50:30 +0200

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

reply via email to

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