Re: persistent bootstrap failure: Memory exhausted--use C-x s ...

[Jim Meyering <jim@meyering.net>]

Jim Meyering wrote:
> Eli Zaretskii wrote:
>>> From: Jim Meyering <jim@meyering.net>
>>> Date: Thu, 20 May 2010 12:30:35 +0200
>>>
>>>   No MH variant found on the system
>>>   Wrote /home/j/w/co/emacs/lisp/mh-e/mh-xface.elc
>>>   Compiling /home/j/w/co/emacs/lisp/language/hanja-util.el
>>>
>>>   In toplevel form:
>>>   ../../../../home/j/w/co/emacs/lisp/language/hanja-util.el:6437:6:Error: Memory exhausted--use C-x s then exit and restart Emacs
>>>   make[2]: *** [language/hanja-util.elc] Error 1
>>>   make[2]: Leaving directory `/t/jt-FqYKau/emacs/lisp'
>>>   make[1]: *** [compile-main] Error 2
>>>   make[1]: Leaving directory `/t/jt-FqYKau/emacs/lisp'
>>>   make: *** [lisp] Error 2
>>>
>>> I can't be the only one configuring to an empty (new prefix)
>>> and running "make bootstrap", so I suppose it's something
>>> in my set-up.  Maybe no one else is doing that with F13...
>>
>> I have just bootstrapped the current trunk on
>>
>>   Linux fencepost 2.6.26-2-xen-amd64 #1 SMP Wed Jan 13 00:12:41 UTC 2010 x86_64 GNU/Linux
>>
>> without any trouble at all.
>>
>>> Both srcdir and non-srcdir builds fail,
>>> with and without this PATH-limiting export:
>>
>> With the same error message and while compiling the same file?
>>
>>> Any suggestions?
>>
>> Can you verify that Emacs indeed uses gobs of memory when it
>> bootstraps?
>>
>> Does F13 have some features that could limit memory of Emacs?
>
> Thanks to you and Chad for the confirmation
> that this is something specific to my setup.
> I should be able to investigate tomorrow.

I've resolved the mystery.
Quick solutions:
  - use MALLOC_CHECK_=0 or don't set the envvar at all
      (i.e., don't set MALLOC_CHECK_=1 or greater), or
  - build with rawhide (with glibc-2.12.90-1), not F13

My using MALLOC_CHECK_=3 appears to have triggered a bug in
glibc's malloc that was fixed upstream barely a month ago, by commit
ad3d3e8f20c95aae9d26970c169bca6f48072681.  It looks like the fix reached
rawhide only very recently: when I built on rawhide minutes ago, I
was able to reproduce the problem, but updating its package set pulled
in glibc-2.12.90-1 (displacing glibc-2.12-1), and then rebuilding
emacs succeeded.