This is the mail archive of the
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Stefan Monnier <monnier at iro dot umontreal dot ca>
- Cc: emacs-devel at gnu dot org, libc-alpha at sourceware dot org
- Date: Sat, 23 Jan 2016 17:50:30 +0200
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4207 dot 4060209 at cs dot ucla dot edu> <569D6AE6 dot 1060008 at redhat dot com> <83bn8icjqu dot fsf at gnu dot org> <jwv60yk7snj dot fsf-monnier+gmane dot emacs dot devel at gnu dot org> <83r3h86aqf dot fsf at gnu dot org> <jwvr3h8uxlc dot fsf-monnier+emacs at gnu dot org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Stefan Monnier <email@example.com>
> Cc: firstname.lastname@example.org, email@example.com
> 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
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.