From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Ken Raeburn , 3892@debbugs.gnu.org Resent-From: Ken Raeburn Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 21 Jul 2009 04:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.124815042530824 (code B ref -1); Tue, 21 Jul 2009 04:35:03 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 21 Jul 2009 04:27:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6L4QxmZ030817 for ; Mon, 20 Jul 2009 21:27:01 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MT6wM-0008O3-Ob for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MT6wM-0008Np-34 for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:58 -0400 Received: from [199.232.76.173] (port=38064 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT6wL-0008Nl-SJ for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:57 -0400 Received: from [76.119.237.235] (port=64696 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MT6wL-0002nx-Gd for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:57 -0400 Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6L41CA5010557; Tue, 21 Jul 2009 00:01:12 -0400 (EDT) Message-Id: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> From: Ken Raeburn To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 00:01:12 -0400 X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 1542 seconds by postgrey-1.27 at monty-python; Tue, 21 Jul 2009 00:26:55 EDT 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 From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Stefan Monnier , 3892@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 21 Jul 2009 16:30:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 3892-submit@emacsbugs.donarmstrong.com id=B3892.124819363126685 (code B ref 3892); Tue, 21 Jul 2009 16:30:07 +0000 Received: (at 3892) by emacsbugs.donarmstrong.com; 21 Jul 2009 16:27:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from tomts22-srv.bellnexxia.net (bc.sympatico.ca [209.226.175.184]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6LGR60J026678 for <3892@emacsbugs.donarmstrong.com>; Tue, 21 Jul 2009 09:27:07 -0700 Received: from toip7.srvr.bell.ca ([209.226.175.124]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090721162706.SKTR19329.tomts22-srv.bellnexxia.net@toip7.srvr.bell.ca> for <3892@emacsbugs.donarmstrong.com>; Tue, 21 Jul 2009 12:27:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAG+JZUpBXrWz/2dsb2JhbACBUdFnhAwFgUA Received: from bas1-montreal02-1096725939.dsl.bell.ca (HELO ceviche.home) ([65.94.181.179]) by toip7.srvr.bell.ca with ESMTP; 21 Jul 2009 12:29:38 -0400 Received: by ceviche.home (Postfix, from userid 20848) id DA137B41BF; Tue, 21 Jul 2009 12:27:05 -0400 (EDT) From: Stefan Monnier To: Ken Raeburn Cc: 3892@debbugs.gnu.org Message-ID: References: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> Date: Tue, 21 Jul 2009 12:27:05 -0400 In-Reply-To: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> (Ken Raeburn's message of "Tue, 21 Jul 2009 00:01:12 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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. Good catch. > 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). I think we should drop the counter altogether, and use specbind instead. Stefan From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Ken Raeburn , 3892@debbugs.gnu.org Resent-From: Ken Raeburn Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 21 Jul 2009 18:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 3892-submit@emacsbugs.donarmstrong.com id=B3892.124820188818825 (code B ref 3892); Tue, 21 Jul 2009 18:50:04 +0000 Received: (at 3892) by emacsbugs.donarmstrong.com; 21 Jul 2009 18:44:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,RDNS_NONE autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from raeburn.org ([76.119.237.235]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6LIihfj018819 for <3892@emacsbugs.donarmstrong.com>; Tue, 21 Jul 2009 11:44:44 -0700 Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6LIigGx002468; Tue, 21 Jul 2009 14:44:42 -0400 (EDT) From: Ken Raeburn To: Stefan Monnier In-Reply-To: References: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 14:44:42 -0400 Cc: 3892@debbugs.gnu.org X-Mailer: Apple Mail (2.935.3) On Jul 21, 2009, at 12:27, Stefan Monnier wrote: > I think we should drop the counter altogether, and use specbind > instead. Much simpler, yes, and it looks like nothing in the C code cares about the numeric value either. Thanks for the suggestion; I'll revise my patch. Ken From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Ken Raeburn , 3892@debbugs.gnu.org Resent-From: Ken Raeburn Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 24 Jul 2009 00:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 3892-submit@emacsbugs.donarmstrong.com id=B3892.124839413726191 (code B ref 3892); Fri, 24 Jul 2009 00:15:04 +0000 Received: (at 3892) by emacsbugs.donarmstrong.com; 24 Jul 2009 00:08:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from raeburn.org (splat.raeburn.org [69.25.196.39]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6O08j5l026182 for <3892@emacsbugs.donarmstrong.com>; Thu, 23 Jul 2009 17:08:46 -0700 Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6O08dcM006583; Thu, 23 Jul 2009 20:08:39 -0400 (EDT) From: Ken Raeburn To: Stefan Monnier In-Reply-To: References: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> Message-Id: <42A7787D-BA88-4613-BE99-F02C44904A1C@raeburn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 20:08:39 -0400 Cc: 3892@debbugs.gnu.org X-Mailer: Apple Mail (2.935.3) On Jul 21, 2009, at 14:44, Ken Raeburn wrote: > On Jul 21, 2009, at 12:27, Stefan Monnier wrote: >> I think we should drop the counter altogether, and use specbind >> instead. > > Much simpler, yes, and it looks like nothing in the C code cares > about the numeric value either. > Thanks for the suggestion; I'll revise my patch. I'm working on the revised patch, but it occurs to me that this way, some broken bit of code could set load-in-progress to t at some point when nothing is being loaded, and it will never become nil again unless explicitly reset. I'm not sure that's right either. I think I kind of like the behavior that while code can temporarily override it, the correct state will be restored from the C code any time it changes (file loading starts or completes). A related issue: If we're changing the way it's set, should we retain the constraint that load-in-progress can only (appear to) hold boolean values, or let it hold any Lisp value instead? Ken From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Stefan Monnier , 3892@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 24 Jul 2009 01:20:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 3892-submit@emacsbugs.donarmstrong.com id=B3892.12483980994673 (code B ref 3892); Fri, 24 Jul 2009 01:20:04 +0000 Received: (at 3892) by emacsbugs.donarmstrong.com; 24 Jul 2009 01:14:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6O1Et9R004657 for <3892@emacsbugs.donarmstrong.com>; Thu, 23 Jul 2009 18:14:56 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAC+oaEpFpZx3/2dsb2JhbACBUc84hA0Fhws X-IronPort-AV: E=Sophos;i="4.43,259,1246852800"; d="scan'208";a="42084367" Received: from 69-165-156-119.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.119]) by ironport2-out.teksavvy.com with ESMTP; 23 Jul 2009 21:14:48 -0400 Received: by pastel.home (Postfix, from userid 20848) id EEC8C84A3; Thu, 23 Jul 2009 21:14:48 -0400 (EDT) From: Stefan Monnier To: Ken Raeburn Cc: 3892@debbugs.gnu.org Message-ID: References: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> <42A7787D-BA88-4613-BE99-F02C44904A1C@raeburn.org> Date: Thu, 23 Jul 2009 21:14:48 -0400 In-Reply-To: <42A7787D-BA88-4613-BE99-F02C44904A1C@raeburn.org> (Ken Raeburn's message of "Thu, 23 Jul 2009 20:08:39 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> I think we should drop the counter altogether, and use specbind instead. >> Much simpler, yes, and it looks like nothing in the C code cares about the >> numeric value either. >> Thanks for the suggestion; I'll revise my patch. > I'm working on the revised patch, but it occurs to me that this way, some > broken bit of code could set load-in-progress to t at some point when > nothing is being loaded, and it will never become nil again unless > explicitly reset. Isn't that a problem that already exists? In any case such setting would be a bug, so I wouldn't worry about it. > A related issue: If we're changing the way it's set, should we retain the > constraint that load-in-progress can only (appear to) hold boolean values, > or let it hold any Lisp value instead? A boolean seems sufficient, I see no need to change it for now, Stefan From unknown Sat Jun 21 05:03:39 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#3892: corrupting load-in-progress value with "let" Reply-To: Ken Raeburn , 3892@debbugs.gnu.org Resent-From: Ken Raeburn Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 24 Jul 2009 01:55:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 3892 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 3892-submit@emacsbugs.donarmstrong.com id=B3892.124840028010264 (code B ref 3892); Fri, 24 Jul 2009 01:55:04 +0000 Received: (at 3892) by emacsbugs.donarmstrong.com; 24 Jul 2009 01:51:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from raeburn.org (splat.raeburn.org [69.25.196.39]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6O1p7JI010257 for <3892@emacsbugs.donarmstrong.com>; Thu, 23 Jul 2009 18:51:08 -0700 Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6O1p1DK002423; Thu, 23 Jul 2009 21:51:02 -0400 (EDT) From: Ken Raeburn To: Stefan Monnier In-Reply-To: References: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> <42A7787D-BA88-4613-BE99-F02C44904A1C@raeburn.org> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 21:51:01 -0400 Cc: 3892@debbugs.gnu.org X-Mailer: Apple Mail (2.935.3) On Jul 23, 2009, at 21:14, Stefan Monnier wrote: >> I'm working on the revised patch, but it occurs to me that this >> way, some >> broken bit of code could set load-in-progress to t at some point >> when >> nothing is being loaded, and it will never become nil again unless >> explicitly reset. > > Isn't that a problem that already exists? Not exactly... in the released code (and trunk before my first change), it can explicitly be set to t at the top level, but it'll be reset to nil after loading another file. And, the bug I was aiming to fix initially, the counter (unseen by Lisp) can be set to 1 from some higher number during nested loading, causing it to be set to nil when returning back to enclosing load calls, but once you get back to the top level the nil value is correct, and when the next load starts from the top level it'll correctly be set to t (temporarily) again. So the specbind version would make the first bug a little worse, though it fixes the second. > In any case such setting would be a bug, so I wouldn't worry about it. Yeah, that's true enough... >> A related issue: If we're changing the way it's set, should we >> retain the >> constraint that load-in-progress can only (appear to) hold boolean >> values, >> or let it hold any Lisp value instead? > > A boolean seems sufficient, I see no need to change it for now, Okay, it doesn't seem like a big deal to me either way. Ken From unknown Sat Jun 21 05:03:39 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: owner@emacsbugs.donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: Ken Raeburn Subject: bug#3892 closed by Chong Yidong (Re: bug#3892: corrupting load-in-progress value with "let") Message-ID: References: <87fxbslllh.fsf@cyd.mit.edu> <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> X-Emacs-PR-Message: they-closed 3892 X-Emacs-PR-Package: emacs Reply-To: 3892@debbugs.gnu.org Date: Sat, 15 Aug 2009 23:15:09 +0000 Content-Type: multipart/mixed; boundary="----------=_1250378109-4961-1" This is a multi-part message in MIME format... ------------=_1250378109-4961-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs package: #3892: corrupting load-in-progress value with "let" It has been closed by Chong Yidong . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Chong Yidong by replying to this email. --=20 3892: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D3892 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1250378109-4961-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 3892-done) by emacsbugs.donarmstrong.com; 15 Aug 2009 23:09:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7FN9ZMC003982 for <3892-done@emacsbugs.donarmstrong.com>; Sat, 15 Aug 2009 16:09:36 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 5195057E21C; Sat, 15 Aug 2009 19:10:34 -0400 (EDT) From: Chong Yidong To: 3892-done@debbugs.gnu.org Subject: Re: bug#3892: corrupting load-in-progress value with "let" Date: Sat, 15 Aug 2009 19:10:34 -0400 Message-ID: <87fxbslllh.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Closing the bug (see 2009-07-25 checkin to trunk by Ken Raeburn). ------------=_1250378109-4961-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by emacsbugs.donarmstrong.com; 21 Jul 2009 04:27:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6L4QxmZ030817 for ; Mon, 20 Jul 2009 21:27:01 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MT6wM-0008O3-Ob for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MT6wM-0008Np-34 for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:58 -0400 Received: from [199.232.76.173] (port=38064 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MT6wL-0008Nl-SJ for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:57 -0400 Received: from [76.119.237.235] (port=64696 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MT6wL-0002nx-Gd for bug-gnu-emacs@gnu.org; Tue, 21 Jul 2009 00:26:57 -0400 Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6L41CA5010557; Tue, 21 Jul 2009 00:01:12 -0400 (EDT) Message-Id: <47712C91-B427-4C1C-8731-F8BE9463A4A3@raeburn.org> From: Ken Raeburn To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: corrupting load-in-progress value with "let" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 00:01:12 -0400 X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 1542 seconds by postgrey-1.27 at monty-python; Tue, 21 Jul 2009 00:26:55 EDT 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 ------------=_1250378109-4961-1--