GNU bug report logs - #9558
Minimal emacs build runs out of memory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9558 in the body.
You can then email your comments to 9558 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 11:18:32 +0100

Amusingly, as I have no problem with a normal build of Emacs 24 on the
same machine.

Emacs bzr main branch, configured as:

./configure --prefix=/home/repo/emacs-minimal/installed --without-pop
--without-sound --without-sync-input --with-x-toolkit=no --without-xpm
--without-jpeg --without-tiff --without-gif --without-png
--without-rsvg --without-xml2 --without-imagemagick --without-xft
--without-libotf --without-m17n-flt --without-toolkit-scroll-bars
--without-xaw3d --without-xim --without-gpm --without-dbus
--without-gconf --without-gsettings --without-selinux --without-gnutls
--without-makeinfo --without-compress-info --without-x

Building on a machine with 2Gb RAM and ~3Gb swap, my build ends:

../lib-src/make-docfile -d /home/rrt/repo/emacs-minimal/src dosfns.o
msdos.o xterm.o xfns.o xmenu.o xselect.o xrdb.o xsmfns.o fringe.o
image.o fontset.o dbusbind.o nsterm.o nsfns.o nsmenu.o nsselect.o
nsimage.o nsfont.o w32.o w32console.o w32fns.o w32heap.o w32inevt.o
w32menu.o w32proc.o w32reg.o w32select.o w32term.o w32xfns.o
w16select.o widget.o xfont.o ftfont.o xftfont.o ftxfont.o gtkutil.o
xsettings.o xgselect.o termcap.o dispnew.o frame.o scroll.o xdisp.o
menu.o  window.o charset.o coding.o category.o ccl.o character.o
chartab.o bidi.o cm.o term.o terminal.o xfaces.o    emacs.o keyboard.o
macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o
minibuf.o fileio.o dired.o cmds.o casetab.o casefiddle.o indent.o
search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o
eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexelf.o
bytecode.o process.o gnutls.o callproc.o region-cache.o sound.o
atimer.o doprnt.o intervals.o textprop.o composite.o xml.o       >
../etc/DOC
../lib-src/make-docfile -a ../etc/DOC -d
/home/rrt/repo/emacs-minimal/src/../lisp `sed -n -e 's| \\\\||' -e
's|^[ 	]*$(lispsource)/||p' /home/rrt/repo/emacs-minimal/src/lisp.mk`
if test "no" = "yes"; then \
	  ln -f temacs emacs; \
	  EMACSLOADPATH=/home/rrt/repo/emacs-minimal/src/../lisp ./emacs -batch \
	    -f list-load-path-shadows || true; \
	else \
	  LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump || exit 1; \
	  ln -f emacs bootstrap-emacs; \
	  ./emacs -batch -f list-load-path-shadows || true; \
	fi
Bus error (core dumped)
make[1]: *** [emacs] Error 1
make[1]: Leaving directory `/home/rrt/repo/emacs-minimal/src'
make: *** [src] Error 2

On looking at the resultant 2Gb core dump, I see:

Core was generated by `/home/rrt/repo/emacs-minimal/src/temacs -batch
-l loadup dump'.
Program terminated with signal 7, Bus error.
#0  0x4007a32c in __pthread_mutex_lock (mutex=0x83871c8) at
pthread_mutex_lock.c:47
47	pthread_mutex_lock.c: No such file or directory.
	in pthread_mutex_lock.c
(gdb) where
#0  0x4007a32c in __pthread_mutex_lock (mutex=0x83871c8) at
pthread_mutex_lock.c:47
#1  0x08120823 in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1260
#2  0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#3  0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#4  0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#5  0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#6  0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#7  0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#8  0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#9  0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#10 0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#11 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#12 0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#13 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
#14 0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#15 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
alloc.c:1269
...
and the stack seems to have eaten much if not most of the memory, as
it goes on the same way up to at least 320,000 (at which point I got
bored of holding down RETURN to produce more backtrace).

-- 
http://rrt.sc3d.org

Message #8 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 06:34:51 -0400

> Date: Tue, 20 Sep 2011 11:18:32 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> #14 0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
> #15 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
> alloc.c:1269
> ...
> and the stack seems to have eaten much if not most of the memory, as
> it goes on the same way up to at least 320,000 (at which point I got
> bored of holding down RETURN to produce more backtrace).

Instead of endless RETURNs, try "where -30" to see the more
interesting and useful part of the backtrace.

Message #11 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 11:45:20 +0100

On 20 September 2011 11:34, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 20 Sep 2011 11:18:32 +0100
>> From: Reuben Thomas <rrt <at> sc3d.org>
>>
>> #14 0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
>> #15 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
>> alloc.c:1269
>> ...
>> and the stack seems to have eaten much if not most of the memory, as
>> it goes on the same way up to at least 320,000 (at which point I got
>> bored of holding down RETURN to produce more backtrace).
>
> Instead of endless RETURNs, try "where -30" to see the more
> interesting and useful part of the backtrace.

Not very interesting, I'm afraid:

(gdb) where -30
/build/buildd/gdb-7.2/gdb/utils.c:1401: internal-error: virtual memory
exhausted: can't allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

-- 
http://rrt.sc3d.org

Message #14 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 07:59:58 -0400

> Date: Tue, 20 Sep 2011 11:45:20 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: 9558 <at> debbugs.gnu.org
> 
> (gdb) where -30
> /build/buildd/gdb-7.2/gdb/utils.c:1401: internal-error: virtual memory
> exhausted: can't allocate 4064 bytes.

Try enlarging the swap space.

Message #17 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 18:10:31 +0300

> Date: Tue, 20 Sep 2011 14:40:43 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> On 20 September 2011 12:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Date: Tue, 20 Sep 2011 11:45:20 +0100
> >> From: Reuben Thomas <rrt <at> sc3d.org>
> >> Cc: 9558 <at> debbugs.gnu.org
> >>
> >> (gdb) where -30
> >> /build/buildd/gdb-7.2/gdb/utils.c:1401: internal-error: virtual memory
> >> exhausted: can't allocate 4064 bytes.
> >
> > Try enlarging the swap space.
> 
> I added 20Gb of swap. Same problem.

"Same problem" with Emacs or with GDB?  I meant to give GDB enough
memory to display some useful backtrace.

If GDB still cannot produce a backtrace, run the failing command under
GDB to begin with, or maybe limit the stack size when temacs runs, to
get it crash earlier with a smaller backtrace.

And please keep debbugs on the CC list.

Message #20 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 18:20:25 +0200

Reuben Thomas <rrt <at> sc3d.org> writes:

> #0  0x4007a32c in __pthread_mutex_lock (mutex=0x83871c8) at
> pthread_mutex_lock.c:47
> #1  0x08120823 in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
> alloc.c:1260
> #2  0x401220d0 in __libc_malloc (bytes=16384) at malloc.c:3622
> #3  0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e) at
> alloc.c:1269

Obviously stack overflow due to endless recursion.  __libc_malloc isn't
supposed to call back into emacs.  You need to find out why
old_malloc_hook was set to emacs_blocked_malloc.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #23 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Tue, 20 Sep 2011 19:53:54 +0100

On 20 September 2011 16:10, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> I added 20Gb of swap. Same problem.
>
> "Same problem" with Emacs or with GDB?  I meant to give GDB enough
> memory to display some useful backtrace.

This was with GDB.

> If GDB still cannot produce a backtrace, run the failing command under
> GDB to begin with, or maybe limit the stack size when temacs runs, to
> get it crash earlier with a smaller backtrace.

(gdb) where -30
#31784 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31785 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31786 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31787 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31788 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31789 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31790 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31791 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31792 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31793 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31794 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31795 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31796 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31797 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31798 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31799 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31800 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31801 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31802 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31803 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31804 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31805 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31806 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31807 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x812082e)
at alloc.c:1269
#31808 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31809 0x0812082e in emacs_blocked_malloc (size=16384, ptr=0x8121f84)
at alloc.c:1269
#31810 0x002160d0 in __libc_malloc (bytes=16384) at malloc.c:3622
#31811 0x08121f84 in refill_memory_reserve () at alloc.c:3432
#31812 0x08126127 in init_alloc_once () at alloc.c:6278
#31813 0x080cae84 in main (argc=<value optimized out>, argv=Cannot
access memory at address 0x5
) at emacs.c:1250

> And please keep debbugs on the CC list.

Apologies, finger trouble.

-- 
http://rrt.sc3d.org

Message #26 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Wed, 14 Dec 2016 13:45:21 -0500

I'm guessing that 5 years on, this report is no longer relevant, so I'm
closing it. Obviously feel free to reopen if needed.

Message #33 received at 9558 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9558 <at> debbugs.gnu.org
Subject: Re: bug#9558: Minimal emacs build runs out of memory
Date: Thu, 15 Dec 2016 00:07:10 +0000

[Message part 1 (text/plain, inline)]

On 14 December 2016 at 18:45, Glenn Morris <rgm <at> gnu.org> wrote:

>
> I'm guessing that 5 years on, this report is no longer relevant, so I'm
> closing it. Obviously feel free to reopen if needed.
>

​You guessed right! This was near the top of my to-do list anyway, so I
checked with an equivalent up-to-date minimal-ish configuration, and was
able to build with no problems. Still builds a 14Mb binary, though! (cf.
vim-basic at 2.4Mb, vim-tiny at 1.1Mb).

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Previous Next

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