This is the mail archive of the libc-alpha@sourceware.org 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]

__malloc_initialize_hook removal in glibc 2.24


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


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