bug#850: 23.0.60; make autoloads reports memory exhaustion

bug#850: 23.0.60; make autoloads reports memory exhaustion

[Chong Yidong]

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

bug#850: 23.0.60; make autoloads reports memory exhaustion

[Tim Van Holder]

On Wed, Sep 3, 2008 at 2:20 AM, Chong Yidong <cyd@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.

bug#850: 23.0.60; make autoloads reports memory exhaustion

[Tim Van Holder]

CVS build of this morning; did a make maintainer-clean followed by a
make boostrap to ensure a clean slate.

My normal "rebuild" script updates the sources and then runs

test -f src/emacs && test -x src/emacs || make
make info
make -C lisp recompile updates
rm -f etc/DOC* src/emacs
make

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.

In case it's relevant, I build outside the source tree.