[net.emacs] 'load' bug

kay@flame.UUCP (Kay Dekker) (11/08/84)

(load "klutz")
	where klutz is a nonexistant file causes Gosling Emacs
	to dump core with a memory fault, whereas
ESC-x load klutz
	comes back with "Can't find klutz"

The problem happens (according to sdb) with the line
    if (!ExecutedDefun && code) free (code);
in compile.c
						Kay...
-- 
"Less an editor than a way of life"

			... mcvax!ukc!qtlon!flame!ubu!kay

chris@umcp-cs.UUCP (Chris Torek) (11/11/84)

This problem [core dump from Emacs #264 when loading functions that
load other functions, and when loading via ESC-ESC (load "foo")] is
due to a rather silly oversight:  the code that runs ``compiled''
MLisp tries to save space by freeing any memory used if no ``defun''s
are executed.  Unfortunately, it uses a single global variable to
control this.  When load is invoked recursively (reentrantly?), it
doesn't save and restore this global.

This can be (has been) fixed in my local Emacs.  You actually need
to save 3 variables (ExecutedDefun, code, and codesize, or something
like that).  This needs to be done in two places, too, I think (in
ExecuteMLispFile in compile.c, and in ExecuteMLispLine in the same
file).  UniPress has these changes; dunno when they'll get them out
to other people.

The problem of one file recursively loading itself is more difficult.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland