[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: persistent bootstrap failure: Memory exhausted--use C-x s ...
From: |
Jim Meyering |
Subject: |
Re: persistent bootstrap failure: Memory exhausted--use C-x s ... |
Date: |
Fri, 21 May 2010 09:58:21 +0200 |
Jim Meyering wrote:
> Eli Zaretskii wrote:
>>> From: Jim Meyering <address@hidden>
>>> 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.