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