From: Jim Meyering <jim@meyering.net>
To: emacs-devel@gnu.org
Subject: Re: persistent bootstrap failure: Memory exhausted--use C-x s ...
Date: Fri, 21 May 2010 09:58:21 +0200 [thread overview]
Message-ID: <87ljbdk7oi.fsf@meyering.net> (raw)
In-Reply-To: <87wruyjnwx.fsf@meyering.net> (Jim Meyering's message of "Thu, 20 May 2010 22:53:02 +0200")
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.
prev parent reply other threads:[~2010-05-21 7:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-20 10:30 persistent bootstrap failure: Memory exhausted--use C-x s Jim Meyering
2010-05-20 16:03 ` Chad Brown
2010-05-20 17:40 ` Eli Zaretskii
2010-05-20 20:53 ` Jim Meyering
2010-05-21 7:58 ` Jim Meyering [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ljbdk7oi.fsf@meyering.net \
--to=jim@meyering.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.