This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Removal of unexec support from glibc malloc

> Cc: Eli Zaretskii <>,,
> From: Florian Weimer <>
> Date: Tue, 26 Jan 2016 23:17:35 +0100
> 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?

AFAIK, Emacs has no reason to call any libraries in temacs except libc
(and its logical extensions, like libm).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]