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, Jul 13, 2016 at 10:52 PM, Dan Horák <dan@danny.cz> wrote:
> 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
Indeed, it affected emacs build on ppc64(le) . emacs build failure on
ppc64(le) was giving message
"Memory exhausted--use M-x save-some-buffers then exit and restart Emacs".
Later on, building emacs (tried on ppc64 machine locally) with
increased memory (~15GB) succeeded.
--
http://sinny.io/