Re: glibc 2.24 -- Release blockers

[Florian Weimer <fweimer@redhat.com>]

On 07/15/2016 12:12 PM, Paul Eggert wrote:
> On 07/15/2016 10:35 AM, Florian Weimer wrote:
>>> I expect such an approach is too much to expect to fold into Emacs 25,
>>> which is close to release. We could try something along those lines for
>>> the next major Emacs release, but that won't be for a while.
>>
>> In this case, I suggest *not* to revert the __malloc_initialize_hook
>> removal because if we put it back in, Emacs will not use its internal
>> malloc, and we get no additional test coverage compared to we had
>> before the removal.
>
> By "test coverage" do you mean some testing by a buildbot that builds
> and runs Emacs with bleeding-edge glibc? If so, we shouldn't need to
> remove __malloc_initialize_hook to test this; all that should be needed
> is './configure emacs_cv_var_doug_lea_malloc=no', which causes Emacs
> 'configure' to pretend that __malloc_initialize_hook does not exist.

I meant testing by Emacs developers and users who use pre-release builds.

The build barely exercises all the libraries Emacs linked into the 
process image.

> How about the following more-conservative approach instead?
>
> 1. Restore __malloc_initialize_hook in glibc.
>
> 2. Try to get Emacs 25 to work even when configured with './configure
> emacs_cv_var_doug_lea_malloc=no'. I'm hoping that something like the
> patch I proposed in
> <https://sourceware.org/ml/libc-alpha/2016-07/msg00458.html> is enough
> to do this, and will be accepted by the Emacs maintainers this close to
> a release.
>
> 3. If (2) is too ambitious for Emacs 25, get it to work with Emacs 26.
> This should be quite doable, as essentially the same thing is already
> working with Cygwin.
>
> 4. Once a stable version of Emacs is published with either (2) or (3),
> then remove __malloc_initialize_hook from glibc.

What worries me is that your proposal still ignores the deprecation of 
__malloc_initialize_hook.  Deprecation means “stop using this 
interface”.  Yet you advocate to keep using it indefinitely, relying on 
glibc pulling trigger at some unspecified point in the future, rather 
than a new Emacs release (which would be much more predictable).  I 
don't see how this ensures progress towards a solution.

We already thought we were at step 4.

If Emacs does not actually exercises the gmalloc code before it is 
force-activated by a glibc change, we won't know which other bugs are 
lurking there.  For example, gmalloc does not interpose 
malloc_usable_size or __libc_memalign, which could cause issues for the 
libraries it links to.  Or the allocator behavior may trigger 
performance issues with some of the graphics libraries.

Florian