This is the mail archive of the
mailing list for the glibc project.
Re: glibc 2.24 -- Release blockers
On 07/14/2016 12:59 PM, Paul Eggert wrote:
On 07/13/2016 07:09 PM, Florian Weimer wrote:
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.
Is this the main problem with Emacs and draft-glibc-2.24 malloc? If so,
can you suggest a patch to Emacs, or a patch to glibc, that will work
around the problem? For example, can Emacs disable the aggressive ASLR
somehow? I assume there is a relatively simple fix to Emacs or to glibc
that could work around this specific problem.
If my analysis is right, src/gmalloc.c assumes that it can allocate an
array which contains three words for every BLOCKSIZE (4096) bytes of the
heap. This assumption is just not valid on 64-bit architectures.
Increasing BLOCKSIZE will help somewhat, but this looks rather like a
core issue with the allocation algorithm.
GDB does this to disable randomization:
errno = 0;
personality_orig = personality (0xffffffff);
if (errno == 0 && !(personality_orig & ADDR_NO_RANDOMIZE))
personality_set = 1;
personality (personality_orig | ADDR_NO_RANDOMIZE);
if (errno != 0 || (personality_set
&& !(personality (0xffffffff) &
warning (_("Error disabling address space randomization: %s"),
(0xffffffff should really be -1.)
I do not know if we can do the above early enough before glibc calls
sbrk internally. Emacs may have to re-exec itself to apply this
successfully. I'm not sure if this approach will be more reliable than
any kludge that is put into gmalloc.