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


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