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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Eli Zaretskii <eliz at gnu dot org>, Emacs-devel at gnu dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 19 Jan 2016 11:14:25 +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> <83mvs2d5b2 dot fsf at gnu dot org> <858u3meiv1 dot fsf at iznogoud dot viz> <569D6A3E dot 2010009 at cs dot ucla dot edu> <569D73D7 dot 1080206 at redhat dot com> <569DD82B dot 20201 at cs dot ucla dot edu> <569E017F dot 6090609 at redhat dot com>
On 01/19/2016 10:27 AM, Florian Weimer wrote:
> On 01/19/2016 07:31 AM, Paul Eggert wrote:
>>> With a bit of luck, newer valgrind versions will even recognize the
>>> interposed malloc, simplifying leak detection.
>> Wow, thanks, I didn't know that. I have been using valgrind only on
>> temacs (the undumped, slow, and hard-to-use Emacs), because valgrind
>> doesn't work on dumped emacs under GNU/Linux.
> With the new interposing-aware valgrind, valgrind still works, but
> there's a memory allocation failure because valgrind detects an invalid
> realloc and makes it return NULL, instead of forwarding it to the
> We're looking at this to see if it's easy to fix in valgrind.
This will not work until the undumping code iterates over all heap
objects and marks them with VALGRIND_MALLOCLIKE_BLOCK. It's not exactly
trivial (but not that hard, either). There might be secondary breakage