GNU bug report logs - #850
23.0.60; make autoloads reports memory exhaustion

Previous Next

Full log

View this message in rfc822 format

From: "Tim Van Holder" <tim.vanholder <at> gmail.com>
To: "Chong Yidong" <cyd <at> stupidchicken.com>
Cc: 850 <at> debbugs.gnu.org
Subject: bug#850: 23.0.60; make autoloads reports memory exhaustion
Date: Wed, 3 Sep 2008 09:55:52 +0200

On Wed, Sep 3, 2008 at 2:20 AM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>> But since this morning the make command for the lisp subdir fails
>> during autoloads processing:
>>
>> Saving file /home/tim/gnu/src/emacs/lisp/loaddefs.el...
>> Memory exhausted--use C-x s then exit and restart Emacs
>> make: *** [autoloads] Error 255
>>
>> loaddefs.el doesn't seem to get updated. It also prevented the other
>> commands for the 'updates' target from running, but I've added -k to
>> the make options to work around that.
>
> I can't reproduce this.  Do you still see this problem with latest CVS?
> If so, what's your platform?

Yes, with an emacs built from CVS (not a full bootstrap) 20 minutes ago,
"make -C lisp autoloads" still reports the memory exhaustion during the
save operation.

A little debugging shows that the signal is raised from memory_full(), which is
called by lisp_malloc; it was asked to allocate 1.2MiB worth of non-lisp memory.
At the point of the memory_full() invocation, val is indeed 0 (and
this is the direct
return value of malloc, not because of further changes to val) - but
at this point
emacs only has 15MiB of memory allocated so there's no way it really ran out
of memory.

My system is a debian linux box, running a 2.4.27 kernel (which I can't upgrade
to 2.6 because the 2.6 kernel dropped support for its Dell RAID controller),
with glibc 2.3.6. Configured using only --with-x.

OK - it looks like this was an extreme edge case.
I just set aside my existing loaddefs.el (unfortunately as
loaddefs.el~, so it was
destroyed in the process) and reran make -C lisp autoloads. While this
took a lot
longer (all files as opposed to the 6 or so that had changed since the
last time),
this completed without error. So it looks like it was some sort of
very rare bug,
presumably in the system malloc.

So I guess you can close this one.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.