This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.24 -- Release blockers
On Wed, 13 Jul 2016 19:09:19 +0200
Florian Weimer <fweimer@redhat.com> wrote:
> On 07/13/2016 03:03 PM, Andreas Schwab wrote:
> > Florian Weimer <fweimer@redhat.com> writes:
> >
> >> I don't see logs for an emacs failure.
> >
> > https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/emacs/p/ppc64
> > https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/emacs/p/ppc64le
>
> Apparently, ppc64 has very aggressive ASLR, and the built-in malloc
> in Emacs assumes that brk will hand out addresses which are close to
> the .data section in the executable: It has a direct mapping from
> addresses to blocks to block information, and if there is a large gap
> between .data and the heap, the block array is huge.
>
> This was not encountered before because Emacs unexec does not support
> 64-bit AIX, and that is probably the only ppc64 target where Emacs
> would use its internal malloc.
>
> ppc64le probably has the same issue, but the latest upstream release
> lacks unexec support, so I can't test it there.
>
> A workaround is to have lots and lots of memory.
I guess it explains also emacs build failure in rawhide -
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3535700
Dan
> I don't know if there is anything on the glibc side that we can
> reasonably do about this matter. I don't want to back out the
> removal of __malloc_initialize_hook from <malloc.h> (which triggers
> the switch to the internal malloc).
>
> Comments?
>
> Florian