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


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