From: "Tim Van Holder" <tim.vanholder@gmail.com>
To: "Chong Yidong" <cyd@stupidchicken.com>
Cc: 850@emacsbugs.donarmstrong.com
Subject: bug#850: 23.0.60; make autoloads reports memory exhaustion
Date: Wed, 3 Sep 2008 09:55:52 +0200 [thread overview]
Message-ID: <d69e7f6a0809030055o4c38404ap147c5d0d07932f6@mail.gmail.com> (raw)
In-Reply-To: <87y72a5bck.fsf@cyd.mit.edu>
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.
next prev parent reply other threads:[~2008-09-03 7:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-03 0:20 bug#850: 23.0.60; make autoloads reports memory exhaustion Chong Yidong
2008-09-03 7:55 ` Tim Van Holder [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-09-01 10:15 Tim Van Holder
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d69e7f6a0809030055o4c38404ap147c5d0d07932f6@mail.gmail.com \
--to=tim.vanholder@gmail.com \
--cc=850@emacsbugs.donarmstrong.com \
--cc=cyd@stupidchicken.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).