Re: __malloc_initialize_hook removal in glibc 2.24

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 22/07/2016 18:15, Florian Weimer wrote:
> 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.

I think 9 releases is more than enough to send the message that the interface will
eventually be removed.  It is roughly 5 years to adjust the code a new interface or
come up with a project based own solution.

> 
> 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).
> 

As noted by Andreas Schwab, glibc is indeed a central part of GNU/Linux.  However
I do not see as a productive way to move forward by being hold hostage of project
that does no adapt to deprecated interfaces.

My understanding here is:

  1. We all agree that '__malloc_initialize_hook' should be deprecated since it
     has multiple issues with multithread programs.

  2. GLIBC deprecated it on 2.14 (2011) and, although we did not set a timeframe
     for interface removal, the idea is to give programs a quite large (almost
     5 years) timeframe to implement the require adjustments.

  3. Unfortunately I see for such cases testing and enablement is usually done
     when the interface is *actually* removed, not when the symbol is marked
     (either by documentation or build markers).  

> 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).
> 

I think we could just revert, but I am afraid it will just repeat for any other
interface we might deprecated.  I think we should stick to current plan release
of remove this interface and work on projects side to get them adjusted.

Also I see a good approach to set a initial timeframe to interface removal from
current deprecated interface and the future ones.  The idea is to document on
both NEWS and header interface which version on GLIBC the interface would be
removed.  We can also track with a bugzilla set to a future version fix.