glibc 2.24 -- Release blockers

[Florian Weimer]

On 07/14/2016 02:16 PM, Sinny Kumari wrote:
> On Thu, Jul 14, 2016 at 5:00 PM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 07/14/2016 12:46 PM, Sinny Kumari wrote:
>>
>>> 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.
>>
>>
>> I expect that the compiled emacs binary will occasionally need ~12 GiB of
>> RAM as well.  Could you check if this is the case?
>
> Yeah, you are right. Running emacs on even a small c file(20 lines)
> uses ~12.2 GB
> memory
>
>> And then run Emacs under “setarch --addr-no-randomize”, to see if it makes a
>> difference.
>
> when I ran emacs under setarch it uses very reasonable amount of memory (few MB)
> Command I used was "setarch ppc64 --addr-no-randomize  emacs foo.c"

Thanks, this is helpful.  It seems that Emacs (or more precisely, the 
glibc startup code) does not call brk very early, so it might be 
feasible to call the personality function from __malloc_initialize_hook.

This is just a fallback option if the hybrid malloc changes cannot be 
applied for some reason.

Florian