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


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