bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

[Cody Rivera]

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

Emacs freezes and leaks memory when I eval the following code from a fresh
startup ("works" in both ielm and *scratch*)

(setq i 1)

(loop
 (setq i (+ i 1))
 (print i))



It occupies more and more memory, and can only be stopped by sending a
termination signal to the process.

Although I discovered this behavior in Debian's version 24.5 on GNU/Linux,
I have been able to replicate it in stock version 25.

The extent of the memory leak is such that the acronym EMACS ends up
expanding to "Eight thousand Megabytes And Constantly Swapping".


The following is information from Emacs's built in bug reporting system


--------------------------------------------------------------------------------------------------------



In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2016-03-19 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:    Debian GNU/Linux 8.7 (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Outline

Minor modes in effect:
  goto-address-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent messages:
<mouse-6> is undefined [49 times]
byte-code: End of buffer [10 times]
<mouse-6> is undefined
<double-mouse-6> is undefined
byte-code: End of buffer
<mouse-6> is undefined
byte-code: End of buffer [2 times]
<mouse-6> is undefined
byte-code: End of buffer
<mouse-7> is undefined [9 times]

Load-path shadows:
/usr/share/emacs/site-lisp/golang-mode/go-mode hides
/usr/share/emacs/24.5/site-lisp/golang-mode/go-mode
/usr/share/emacs/site-lisp/golang-mode/go-mode-load hides
/usr/share/emacs/24.5/site-lisp/golang-mode/go-mode-load
/usr/share/emacs/24.5/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/site-lisp/rst hides
/usr/share/emacs/24.5/lisp/textmodes/rst
/usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/24.5/lisp/textmodes/flyspell
/usr/share/emacs24/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/24.5/lisp/textmodes/ispell
/usr/share/emacs/24.5/lisp/emacs-lisp/cl-lib hides
/usr/share/emacs/24.5/site-lisp/slime/lib/cl-lib
/usr/share/emacs/24.5/lisp/emacs-lisp/ert-x hides
/usr/share/emacs/24.5/site-lisp/slime/lib/ert-x
/usr/share/emacs/24.5/lisp/emacs-lisp/ert hides
/usr/share/emacs/24.5/site-lisp/slime/lib/ert

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils misearch multi-isearch goto-addr
thingatpt noutline outline view debian-el debian-el-loaddefs
slime-autoloads cl-macs haskell-mode-autoloads edmacro kmacro cl gv
cl-loaddefs cl-lib go-mode-load emacs-goodies-el emacs-goodies-custom
emacs-goodies-loaddefs easy-mmode devhelp time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 90947 5694)
 (symbols 48 19180 0)
 (miscs 40 126 338)
 (strings 32 13692 4629)
 (string-bytes 1 425984)
 (vectors 16 10243)
 (vector-slots 8 393157 8288)
 (floats 8 67 474)
 (intervals 56 967 10)
 (buffers 960 12)
 (heap 1024 33451 962))

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

bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

[Paul Eggert]

I can't reproduce the problem by running 'emacs -Q' with emacs 24.5 or any later 
version. I tried running your code in *scratch* by typing C-j after the two 
expressions. The latter one signaled a Lisp error (void-function loop). If I 
replaced "loop" with "while t" the program output a lot of numbers and stopped 
promptely when I typed C-g. I was running on Fedora 25 x86-64. Perhaps you could 
help move things forward by giving precise instructions on how to reproduce the 
problem from a freshly running "emacs -Q".

bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

[Paul Eggert]

Cody Rivera wrote:
> I must have some emacs package that allows the form "(loop @body)" to be
> used.

Yes, evidently your problem involves some code that I don't have, which explains 
why I can't reproduce it. If you can provide a way to reproduce your problem 
(i.e., C-g does not work) then perhaps we can fix it.

> I reran similar code with emacs -Q, and it turns out I can stop it.  After
> about fifteen seconds, the buffer was populated with millions of lines
> (about 300 million while composing my reply).  Clearly my mundane code was
> running properly.
>
> However, while running the code, my installed versions of Emacs remain
> unresponsive until interrupted -- none of the GUI elements are responsive,
> no command works except C-g, there is no terminal output, and there is
> ultimately no indication that the program is running properly.
>
> I misinterpreted (the lack of) a feature as a bug.

Yes, that's to be expected. Emacs is single-threaded, and if are running Lisp 
code it cannot respond to other keystrokes to run any other Lisp code; all you 
can do is interrupt it with C-g.

bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

[Paul Eggert]

Cody Rivera wrote:
> The file that provided the (loop @body) common lisp style macro is
> cl-macs.el.  My particular problem, however, most likely does not involve
> Emacs or any third-party elisp code, because I can interrupt the code fine.
>
> Even though I would prefer if it allowed access to other commands while
> running code, what is happening is "to be expected" from Emacs.
>
> Thank you for taking the time to respond to my concerns.

I'll mark the bug as wishlist, then. Most likely it'll take quite some time for 
the wish to be granted, unfortunately.

bug#26530: Emacs 24.5, 25; Lisp Interpreter Bug

[Glenn Morris]

It doesn't benefit anyone to keep this report open, so I'll close it.
There are so many open reports that it is hard to find things.

It's well-known that this is how Emacs works.
No developer is going to be inspired to take up working on this issue
because of this report.
No user is going to be first informed about this issue through
reading this report.

If this does ever change, it will be well advertised.