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]

Re: glibc 2.24 -- Release blockers


On Thu, 2016-07-14 at 10:50 +0200, Florian Weimer wrote:
> On 07/14/2016 10:41 AM, Andreas Schwab wrote:
> > Torvald Riegel <triegel@redhat.com> writes:
> >> IIRC, Florian started this several months ago, so it seems emacs should
> >> have had enough time to catch up by now.  Also, bugs in their own malloc
> >> replacement hardly seem like something we'd be responsible for.
> >
> > We are responsible for removing a supported interface.
> 
> The interface was deprecated in 2011.  Existing binaries continue to 
> work, which is something we did not think possible in the past.
> 
> Five years should have been plenty of time for Emacs to adjust.  The 
> problem was raised repeatedly on the emacs-devel list (not just this year).
> 
> Emacs 25 will still use the deprecated __malloc_initialize_hook if it 
> can, significantly reducing test coverage for the src/gmalloc.c 
> allocator.  (The unexec code does not work on many non-Linux 64 bit 
> platforms, so the 64-bit issue with that allocator went unnoticed so far.)
> 
> I'm not sure about the way forward.  This Emacs dependency blocks any 
> non-trivial change to glibc malloc, and we have security and performance 
> issues to address.

So, Emacs had plenty of time to fix this, was notified repeatedly, we
helped them as far as they could, and they still don't do anything on
their side?

If we have to choose between security and performance projects for
almost all programs (except Emacs) vs. making it easier for Emacs to
pretend that the world around them doesn't move, then I'm sure that I'd
pick the former.


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