This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Stefan Monnier <monnier at iro dot umontreal dot ca>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: emacs-devel at gnu dot org, libc-alpha at sourceware dot org
- Date: Sat, 23 Jan 2016 10:29:33 -0500
- 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>
> 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. 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)).
Stefan