[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#3892: marked as done (corrupting load-in-progress value with "let")

From: Emacs bug Tracking System
Subject: bug#3892: marked as done (corrupting load-in-progress value with "let")
Date: Sat, 15 Aug 2009 23:15:09 +0000

Your message dated Sat, 15 Aug 2009 19:10:34 -0400
with message-id <address@hidden>
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 address@hidden

3892: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3892
Emacs Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: corrupting load-in-progress value with "let" Date: Tue, 21 Jul 2009 00:01:12 -0400
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).


--- End Message ---
--- Begin Message --- Subject: Re: bug#3892: corrupting load-in-progress value with "let" Date: Sat, 15 Aug 2009 19:10:34 -0400
Closing the bug (see 2009-07-25 checkin to trunk by Ken Raeburn).

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]