This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
__malloc_initialize_hook removal in glibc 2.24
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 22 Jul 2016 23:15:33 +0200
- Subject: __malloc_initialize_hook removal in glibc 2.24
- Authentication-results: sourceware.org; auth=none
I would like to obtain an explicit decision about the removal of
__malloc_initialize_hook in glibc 2.24.
The situation is roughly this: __malloc_initialize_hook was deprecated
in 2011. Emacs keeps using it to this day, ignoring the deprecation
(and despite multiple warnings on emacs-devel that the interface is
going away). As a result, the fallback code in Emacs in src/gmalloc.c
has not seen much test coverage on GNU/Linux systems. Testing in
OpenSUSE and Fedora uncovered an issue on ppc64/ppc64le. Other
platforms may have problems as well.
We have a chicken-and-egg issue here. Until Emacs starts using
src/gmalloc.c on GNU/Linux (or gets rid of the non-portable dumper, but
this is going to be a far more radical change), src/gmalloc.c will not
see much test coverage (particularly on GNU/Linux). Less coverage means
that bugs remain, and glibc cannot remove __malloc_initialize_hook (or
take other measures to disable heap dumping support) because that would
break Emacs for too many users (well, those users who compile their own
Emacs binaries and are on bleeding-edge glibc versions, which can't be
that many).
I discussed the matter with Carlos and our Emacs maintainer, and we can
implement the API removal in the upcoming Fedora 25 release (which uses
glibc 2.24 and Emacs 25), even if glibc 2.24 upstream releases with
__malloc_initialize_hook. Fedora 25 should see sufficiently wide use
across architectures to iron out any gmalloc wrinkles. This means that
we can reconsider upstream removal for glibc 2.25 (and I really wish to
avoid delaying removal further).
Considering the above, we could revert the __malloc_initialize_hook
removal for the glibc 2.24 release if that is what people what. My
objections to the revert are mainly philosophical in nature (it's
essentially rewarding a reckless disregard for deprecation notices) and
less technical (because it seems we can get the required gmalloc testing
after all).
Thanks,
Florian