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 09:00:56 +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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Stefan Monnier <firstname.lastname@example.org>
> Date: Sat, 23 Jan 2016 00:49:02 -0500
> Cc: email@example.com
> >> This is less of a problem if Emacs never frees a pointer after dump that
> >> it has allocated before dump. But I think this can happen (otherwise,
> >> all this would be quite easy to address).
> > Yes, it can and does happen, although not much.
> Indeed. This said, it'd make sense to try and avoid doing it.
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
It's easy to catch all those cases by setting a breakpoint on realloc
and free during startup.