bug#9558: Minimal emacs build runs out of memory

bug#9558: Minimal emacs build runs out of memory

[Reuben Thomas]

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

bug#9558: Minimal emacs build runs out of memory

[Eli Zaretskii]

> Date: Tue, 20 Sep 2011 11:18:32 +0100
> From: Reuben Thomas <rrt@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.

bug#9558: Minimal emacs build runs out of memory

[Reuben Thomas]

On 20 September 2011 11:34, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 20 Sep 2011 11:18:32 +0100
>> From: Reuben Thomas <rrt@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

bug#9558: Minimal emacs build runs out of memory

[Eli Zaretskii]

> Date: Tue, 20 Sep 2011 11:45:20 +0100
> From: Reuben Thomas <rrt@sc3d.org>
> Cc: 9558@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.

bug#9558: Minimal emacs build runs out of memory

[Eli Zaretskii]

> Date: Tue, 20 Sep 2011 14:40:43 +0100
> From: Reuben Thomas <rrt@sc3d.org>
> 
> On 20 September 2011 12:59, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Tue, 20 Sep 2011 11:45:20 +0100
> >> From: Reuben Thomas <rrt@sc3d.org>
> >> Cc: 9558@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.

bug#9558: Minimal emacs build runs out of memory

[Andreas Schwab]

Reuben Thomas <rrt@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9558: Minimal emacs build runs out of memory

[Reuben Thomas]

On 20 September 2011 16:10, Eli Zaretskii <eliz@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

bug#9558: Minimal emacs build runs out of memory

[Glenn Morris]

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.

bug#9558: Minimal emacs build runs out of memory

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On 14 December 2016 at 18:45, Glenn Morris <rgm@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

[-- Attachment #2: Type: text/html, Size: 1032 bytes --]