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

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

[Jim Meyering]

Hello,

I normally bootstrap the latest emacs (updating sources from git daily),
but for the last ~9 days it's been failing on x86_64 Fedora 13:

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

Both srcdir and non-srcdir builds fail,
with and without this PATH-limiting export:

  export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/bin/X11
  ./configure --prefix=$prefix && make bootstrap

Any suggestions?

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

[Chad Brown]

I don't currently have a Fedora system easily accessible, but I can verify that I don't see this problem on macosx (10.6.3), where I bootstrap (from bzr) with relative frequency.

As a workaround, assuming that you don't need hanja character support, you could probably manually gut the gigantic lambda in hanja-init-load down to one or two entries.

Hope that helps,
*Chad

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

[Eli Zaretskii]

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

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

[Jim Meyering]

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.

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

[Jim Meyering]

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.