This is the mail archive of the
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: rms at gnu dot org
- Cc: Eli Zaretskii <eliz at gnu dot org>, libc-alpha at sourceware dot org, monnier at iro dot umontreal dot ca, emacs-devel at gnu dot org
- Date: Tue, 26 Jan 2016 23:17:35 +0100
- 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> <E1aN72k-00024K-Ep at fencepost dot gnu dot org>
On 01/23/2016 11:52 PM, Richard Stallman wrote:
[realloc/free of a dumped heap object]
> It may be a pain to fix them if they happen inside libraries.
I think the dump-and-reload cycle resets global variables defined in
libraries as long as they are not referenced by the main program. This
means libraries have difficulties to retain references to objects
allocated before the dump.
If Emacs retains such references and passes them to a library, such
boundary-crossing heap operations could still happen. But some
libraries will get very confused if they are handed an object while
their internal state says they have not created any objects yet. (Which
is how we got __malloc_get_state and __malloc_set_state, I assume.)
Has it already happened that an innocent-looking library change causes
existing Emacs binaries to break? Apart from when glibc tried to fix
the incorrect object alignment on 32-bit PowerPC?