GNU bug report logs - #23760
25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23760 in the body.
You can then email your comments to 23760 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jsynacek <at> redhat.com (Jan Synáček)
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 13 Jun 2016 12:48:39 +0200

Emacs doesn't build with the latest glibc (glibc-2.23-90):

  CC       gmalloc.o
../../src/gmalloc.c:273:15: error: attempt to use poisoned "__malloc_initialize_hook"
 extern void (*__malloc_initialize_hook) (void);
               ^
../../src/gmalloc.c:381:8: error: attempt to use poisoned "__malloc_initialize_hook"
 void (*__malloc_initialize_hook) (void);
        ^
../../src/gmalloc.c: In function 'malloc_initialize_1':
../../src/gmalloc.c:567:7: error: attempt to use poisoned "__malloc_initialize_hook"
   if (__malloc_initialize_hook)
       ^
../../src/gmalloc.c:568:7: error: attempt to use poisoned "__malloc_initialize_hook"
     (*__malloc_initialize_hook) ();
       ^

-- 
Jan Synacek
Software Engineer, Red Hat

Message #10 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: jsynacek <at> redhat.com (Jan Synáček)
Cc: 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 13 Jun 2016 11:58:50 -0400

Jan Synáček wrote:

> Emacs doesn't build with the latest glibc (glibc-2.23-90):
>
>   CC       gmalloc.o
> ../../src/gmalloc.c:273:15: error: attempt to use poisoned "__malloc_initialize_hook"

I guess this might be fixed already?

https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html
"Revert symbol poisoning of  __malloc_initialize_hook."

Message #13 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Jan Synacek <jsynacek <at> redhat.com>
To: 23760 <at> debbugs.gnu.org
Cc: Florian Weimer <fweimer <at> redhat.com>, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Tue, 14 Jun 2016 08:09:24 +0200

On Mon, Jun 13, 2016 at 5:58 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> Jan Synáček wrote:
>
>> Emacs doesn't build with the latest glibc (glibc-2.23-90):
>>
>>   CC       gmalloc.o
>> ../../src/gmalloc.c:273:15: error: attempt to use poisoned "__malloc_initialize_hook"
>
> I guess this might be fixed already?
>
> https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html
> "Revert symbol poisoning of  __malloc_initialize_hook."

It was my understanding that this needed to be fixed in both glibc and Emacs.

-- 
Jan Synacek
Software Engineer, Red Hat

Message #16 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Jan Synacek <jsynacek <at> redhat.com>, 23760 <at> debbugs.gnu.org
Cc: Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Tue, 14 Jun 2016 08:17:22 +0200

On 06/14/2016 08:09 AM, Jan Synacek wrote:
> On Mon, Jun 13, 2016 at 5:58 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>> Jan Synáček wrote:
>>
>>> Emacs doesn't build with the latest glibc (glibc-2.23-90):
>>>
>>>   CC       gmalloc.o
>>> ../../src/gmalloc.c:273:15: error: attempt to use poisoned "__malloc_initialize_hook"
>>
>> I guess this might be fixed already?
>>
>> https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html
>> "Revert symbol poisoning of  __malloc_initialize_hook."
>
> It was my understanding that this needed to be fixed in both glibc and Emacs.

Correct, Emacs should not use symbols in the implementation namespace.

Names such as __malloc_initialize_hook (with two leading underscores) 
could be reserved by other implementations as well, not just glibc.

Thanks,
Florian

Message #21 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Synáček <jsynacek <at> redhat.com>
Cc: Florian Weimer <fweimer <at> redhat.com>, Glenn Morris <rgm <at> gnu.org>,
 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Sun, 19 Jun 2016 05:02:17 +0200

If I understand things correctly, the Emacs 'configure' script 
discovered that the test glibc version did not declare and define a 
symbol __malloc_initialize_hook, and so Emacs supplied its own 
implementation of malloc, complete with __malloc_initialize_hook. Since 
__malloc_initialize_hook was poisoned, this didn't work.

I suppose Emacs could work around the problem by using 
__malloc_initialize_hook when linked against an old glibc, and by using 
a new symbol emacs_malloc_initialize_hook when linked against its 
substitute implementation. Although this would insulate distant-future 
versions of Emacs against the poisoning, it wouldn't work for Emacs 25 
(the next Emacs version) and earlier; these systems would be unbuildable 
with a glibc that poisons __malloc_initialize_hook. So as a practical 
matter, aren't we better off having glibc simply not declare 
__malloc_initialize_hook? That should work with older Emacs versions, 
which is a win. I don't see a significant practical advantage to 
poisoning the symbol.

Message #24 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 10:48:19 +0200

On 06/19/2016 05:02 AM, Paul Eggert wrote:
> If I understand things correctly, the Emacs 'configure' script
> discovered that the test glibc version did not declare and define a
> symbol __malloc_initialize_hook, and so Emacs supplied its own
> implementation of malloc, complete with __malloc_initialize_hook. Since
> __malloc_initialize_hook was poisoned, this didn't work.

Yes, that's right.  I didn't account for the possibility that Emacs 
would use symbols in the implementation namespace for implementing its 
own malloc.

> I suppose Emacs could work around the problem by using
> __malloc_initialize_hook when linked against an old glibc, and by using
> a new symbol emacs_malloc_initialize_hook when linked against its
> substitute implementation. Although this would insulate distant-future
> versions of Emacs against the poisoning, it wouldn't work for Emacs 25
> (the next Emacs version) and earlier; these systems would be unbuildable
> with a glibc that poisons __malloc_initialize_hook. So as a practical
> matter, aren't we better off having glibc simply not declare
> __malloc_initialize_hook?

You mean, not declare it in <malloc.h>?  I already posted a patch for that:

  <https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html>

I'm more worried about the other __ variables in the Emacs malloc. 
Their in Emacs definition does not even match the one in glibc.  The 
difference is probably harmless, but it is fairly close to be being broken.

Thanks,
Florian

Message #27 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Florian Weimer <fweimer <at> redhat.com>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 11:03:02 +0200

On 06/20/2016 10:48 AM, Florian Weimer wrote:
>> aren't we better off having glibc simply not declare
>> __malloc_initialize_hook?
>
> You mean, not declare it in <malloc.h>?

Yes, that's what I meant.

>
> I'm more worried about the other __ variables in the Emacs malloc. 
> Their in Emacs definition does not even match the one in glibc. The 
> difference is probably harmless, but it is fairly close to be being 
> broken.

The intent is that __malloc_initialize_hook and the other __ variables 
will become inoperative in glibc, right? That is, glibc won't set or use 
or care about these obsolete variables. If so, we should be OK with 
Emacs master as-is: when it substitutes its own (even-more-obsolescent) 
malloc it will set and use these variables freely, and this won't 
collide with any glibc use.

Message #30 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 11:21:58 +0200

On 06/20/2016 11:03 AM, Paul Eggert wrote:

>> I'm more worried about the other __ variables in the Emacs malloc.
>> Their in Emacs definition does not even match the one in glibc. The
>> difference is probably harmless, but it is fairly close to be being
>> broken.
>
> The intent is that __malloc_initialize_hook and the other __ variables
> will become inoperative in glibc, right?

No, we need to preserve the past behavior of the hooks for old binaries.

The usual mechanism for deprecation and removal of an API does not work 
if the symbol is interposed because it will be unversioned, and 
unversioned symbols preempt versioned symbols.  As a result, even if the 
symbol is a compat symbol, you can produce new binaries which use the 
removed API.

> That is, glibc won't set or use
> or care about these obsolete variables.

If we did that, old Emacs binaries would stop working because Emacs uses 
__malloc_initialize_hook to call malloc_set_state, which essential for 
restoring the dumped heap.

Florian

Message #33 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Florian Weimer <fweimer <at> redhat.com>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 12:04:50 +0200

On 06/20/2016 11:21 AM, Florian Weimer wrote:
>
> The usual mechanism for deprecation and removal of an API does not 
> work if the symbol is interposed because it will be unversioned, and 
> unversioned symbols preempt versioned symbols.  As a result, even if 
> the symbol is a compat symbol, you can produce new binaries which use 
> the removed API.
>

True, but in this particular case Emacs is replacing malloc as well as 
__malloc_initialize_hook etc., so I don't see a problem. Although new 
Emacs binaries will still use the removed API, they will also support 
the removed API.

What *could* be a problem is if the new glibc malloc API supplies 
symbols that Emacs does not supply, and if other parts of the new glibc 
use these symbols. But I don't see this happening either (and if it did 
happen, poisoning __malloc_initialize_hook wouldn't fix it).

Perhaps poisoning __malloc_initialize_hook helps for some theoretical 
applications, but for Emacs I don't see how it is a win.

Message #36 received at 23760 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Jan Synáček
 <jsynacek <at> redhat.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 23760 <at> debbugs.gnu.org
Subject: Re: bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Mon, 20 Jun 2016 12:15:40 +0200

On 06/20/2016 12:04 PM, Paul Eggert wrote:
> On 06/20/2016 11:21 AM, Florian Weimer wrote:
>>
>> The usual mechanism for deprecation and removal of an API does not
>> work if the symbol is interposed because it will be unversioned, and
>> unversioned symbols preempt versioned symbols.  As a result, even if
>> the symbol is a compat symbol, you can produce new binaries which use
>> the removed API.
>>
>
> True, but in this particular case Emacs is replacing malloc as well as
> __malloc_initialize_hook etc., so I don't see a problem. Although new
> Emacs binaries will still use the removed API, they will also support
> the removed API.

You need just one linked DSOs which somehow manages to call a function 
in the glibc malloc implementation, and interesting things will happen.

> What *could* be a problem is if the new glibc malloc API supplies
> symbols that Emacs does not supply, and if other parts of the new glibc
> use these symbols. But I don't see this happening either (and if it did
> happen, poisoning __malloc_initialize_hook wouldn't fix it).

We already have this problem with malloc_usable_size, and perhaps some 
of the aligned allocation functions.

This reminds me of this glibc bug, which I've put on my list to fix:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=17730>

I think after that, at least glibc will be interposition-clean.

> Perhaps poisoning __malloc_initialize_hook helps for some theoretical
> applications, but for Emacs I don't see how it is a win.

I'm worried that Emacs developers decide to ignore the API removal and 
keep using glibc malloc and the malloc_set_state function it provides. 
If we can turn the latter into a compatibility symbol during this 
development cycle, that would go a long way towards addressing my concern.

Florian

Message #41 received at 23760-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 23760-done <at> debbugs.gnu.org
Subject: Re: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90
Date: Wed, 6 Jul 2016 15:29:43 +0200

As this incompatibility was fixed in glibc commit 
92e1ab0eb58c57d5843fa982ff6c24f551f2f634, I'm closing the Emacs bug 
report. Obviously we have some longer-term issues to address, but the 
problem prompting this bug report appears to have been fixed on the 
glibc side.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.