GNU bug report logs -
#3892
corrupting load-in-progress value with "let"
Previous Next
Reported by: Ken Raeburn <raeburn <at> raeburn.org>
Date: Tue, 21 Jul 2009 04:35:03 UTC
Severity: normal
Done: Chong Yidong <cyd <at> stupidchicken.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 15 Aug 2009 19:10:34 -0400
with message-id <87fxbslllh.fsf <at> cyd.mit.edu>
and subject line Re: bug#3892: corrupting load-in-progress value with "let"
has caused the Emacs bug report #3892,
regarding corrupting load-in-progress value with "let"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact help-debbugs <at> gnu.org
immediately.)
--
3892: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3892
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
With these source files:
==> test.el <==
(message "test: load-in-progress %S" load-in-progress)
(let ((load-path (cons "." load-path)))
(load "test2"))
(message "test: load-in-progress %S" load-in-progress)
==> test2.el <==
(message "test2: load-in-progress %S" load-in-progress)
(load "test3")
(message "test2: load-in-progress %S" load-in-progress)
==> test3.el <==
(message "test3: load-in-progress %S" load-in-progress)
and test.el and test2.el byte-compiled but test3.el only present in
source form, the resulting output shows that load-in-progress is
inconsistent:
% ./b/Inst/bin/emacs --batch -l test.elc
test: load-in-progress t
Loading test2...
test2: load-in-progress t
Loading /tmp/emacs-23.0.96/test3.el (source)...
test3: load-in-progress t
test2: load-in-progress t
test: load-in-progress nil
%
I'm working with the CVS sources and 23.0.96 prerelease code, but can
reproduce the behavior in 22.1 as shipped with Mac OS X.
The variable load-in-progress is defined in the C code with
DEFVAR_BOOL applied to an int variable. Since file loading can be
invoked recursively, the int value is incremented and decremented when
loading begins and ends, and should in theory be zero only when no
file is being loaded.
However, if we're loading a .el file from source, the C code in
lread.c:Fload calls out to the load-source-file-function, which winds
up calling code in mule.el, which uses "let" on load-in-progress. The
let/unwind support doesn't save and restore the integer value for a
Lisp_Misc_Boolfwd variable, just the boolean state. So after loading
of test3.el finishes above, load-in-progress is restored from its old
*boolean* value, and gets the value 1 instead of 2 as it should have.
When test2.elc is done loading, it drops to zero and it looks like
we're not currently loading any files, even though we're in the middle
of loading test.elc still.
There is code (in C mode, among others) which checks whether a file is
being loaded, so this can have a behavioral impact under certain
conditions. I haven't actually triggered the problem in my normal
usage patterns though.
On the assumption that DEFVAR_BOOL variables really ought to just be
used as booleans (I haven't checked other boolean variables though),
and we don't want to change the Lisp-visible binding to an integer (or
"if load-in-progress" would stop working right), I'm working on a
patch to make load-in-progress an actual boolean, and put the file-
loading depth counter elsewhere, inaccessible to Lisp (since it's
inaccessible now).
Ken
[Message part 3 (message/rfc822, inline)]
Closing the bug (see 2009-07-25 checkin to trunk by Ken Raeburn).
This bug report was last modified 15 years and 283 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.