* bug#9558: Minimal emacs build runs out of memory
@ 2011-09-20 10:18 Reuben Thomas
2011-09-20 10:34 ` Eli Zaretskii
2011-09-20 16:20 ` Andreas Schwab
0 siblings, 2 replies; 9+ messages in thread
From: Reuben Thomas @ 2011-09-20 10:18 UTC (permalink / raw)
To: 9558
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#9558: Minimal emacs build runs out of memory
2011-09-20 10:18 bug#9558: Minimal emacs build runs out of memory Reuben Thomas
@ 2011-09-20 10:34 ` Eli Zaretskii
2011-09-20 10:45 ` Reuben Thomas
2011-09-20 16:20 ` Andreas Schwab
1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2011-09-20 10:34 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 9558
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#9558: Minimal emacs build runs out of memory
2011-09-20 10:34 ` Eli Zaretskii
@ 2011-09-20 10:45 ` Reuben Thomas
2011-09-20 11:59 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Reuben Thomas @ 2011-09-20 10:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9558
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#9558: Minimal emacs build runs out of memory
2011-09-20 10:18 bug#9558: Minimal emacs build runs out of memory Reuben Thomas
2011-09-20 10:34 ` Eli Zaretskii
@ 2011-09-20 16:20 ` Andreas Schwab
1 sibling, 0 replies; 9+ messages in thread
From: Andreas Schwab @ 2011-09-20 16:20 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 9558
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."
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-12-15 0:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-20 10:18 bug#9558: Minimal emacs build runs out of memory Reuben Thomas
2011-09-20 10:34 ` Eli Zaretskii
2011-09-20 10:45 ` Reuben Thomas
2011-09-20 11:59 ` Eli Zaretskii
[not found] ` <CAOnWdoieNYmunkgteYnDBDnHj4RY-5+PPFteDAhtdzFnKO2fcg@mail.gmail.com>
2011-09-20 15:10 ` Eli Zaretskii
2011-09-20 18:53 ` Reuben Thomas
2016-12-14 18:45 ` Glenn Morris
2016-12-15 0:07 ` Reuben Thomas
2011-09-20 16:20 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.