[armedbear-devel] bug in FASL loader
Hello. I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl. Consider the following code: (defmacro foo-bar (s) `(sublis '((foo . bar)) ,s)) (defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it))) Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis". -- Durward McDonell durward.mcdonell@jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell <durward.mcdonell@jhuapl.edu> wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi! What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading? Cheers Alessio
Wow, I get some really weird stuff testing this with the latest trunk as follows. (I put his code in a file named yyy.lisp. I did not compile it. There is no yyy.fasl) Blake-Mac-17:tmp blake$ abcl Armed Bear Common Lisp 1.1.0-dev-svn-14015 Java 1.6.0_33 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.369 seconds. Startup completed in 1.371 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "yyy.lisp") T CL-USER(2): (foo-bar-rb) (foo-bar '(foo)) Maximum error depth exceeded (11 nested errors) with 'FASL version mismatch; found '57' but expected '39' in with-standard-io-syntax'. CL-USER(3): I don't get the whole FASL stuff. Blake On Mon, Jul 23, 2012 at 5:40 PM, Alessio Stalla <alessiostalla@gmail.com>wrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell <durward.mcdonell@jhuapl.edu> wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Cheers Alessio
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Tue, Jul 24, 2012 at 2:56 AM, Blake McBride <blake@mcbride.name> wrote:
Wow, I get some really weird stuff testing this with the latest trunk as follows. (I put his code in a file named yyy.lisp. I did not compile it. There is no yyy.fasl)
Blake-Mac-17:tmp blake$ abcl Armed Bear Common Lisp 1.1.0-dev-svn-14015 Java 1.6.0_33 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.369 seconds. Startup completed in 1.371 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "yyy.lisp") T CL-USER(2): (foo-bar-rb) (foo-bar '(foo))
Maximum error depth exceeded (11 nested errors) with 'FASL version mismatch; found '57' but expected '39' in with-standard-io-syntax'. CL-USER(3):
I don't get the whole FASL stuff.
To me it smells like the file with the definition of with-standard-io-syntax is autoloaded with *read-base* set to 16; in fact, #x39 = 57. With-standard-io-syntax is used when loading a FASL exactly to prevent this kind of bugs, so probably it should be preloaded at startup to solve the chicken-and-egg problem. Alessio
On Mon, Jul 23, 2012 at 5:40 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell <durward.mcdonell@jhuapl.edu> wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Cheers Alessio
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
-- Some gratuitous spam: http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
Has this been bug ticket number? On Tue, Jul 24, 2012 at 2:54 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:
On Tue, Jul 24, 2012 at 2:56 AM, Blake McBride <blake@mcbride.name> wrote:
Wow, I get some really weird stuff testing this with the latest trunk as follows. (I put his code in a file named yyy.lisp. I did not compile it. There is no yyy.fasl)
Blake-Mac-17:tmp blake$ abcl Armed Bear Common Lisp 1.1.0-dev-svn-14015 Java 1.6.0_33 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.369 seconds. Startup completed in 1.371 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "yyy.lisp") T CL-USER(2): (foo-bar-rb) (foo-bar '(foo))
Maximum error depth exceeded (11 nested errors) with 'FASL version mismatch; found '57' but expected '39' in with-standard-io-syntax'. CL-USER(3):
I don't get the whole FASL stuff.
To me it smells like the file with the definition of with-standard-io-syntax is autoloaded with *read-base* set to 16; in fact, #x39 = 57.
With-standard-io-syntax is used when loading a FASL exactly to prevent this kind of bugs, so probably it should be preloaded at startup to solve the chicken-and-egg problem.
Alessio
On Mon, Jul 23, 2012 at 5:40 PM, Alessio Stalla <alessiostalla@gmail.com
wrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell <durward.mcdonell@jhuapl.edu> wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Cheers Alessio
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
-- Some gratuitous spam:
http://ripple-project.org Ripple, social credit system http://villages.cc Villages.cc, Ripple-powered community economy http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM http://code.google.com/p/tapulli my current open source projects http://www.manydesigns.com/ ManyDesigns Portofino, open source model-driven Java web application framework
Thanks! On Sun, Jul 29, 2012 at 10:24 AM, Erik Huelsmann <ehuels@gmail.com> wrote:
On Sun, Jul 29, 2012 at 1:28 PM, Blake McBride <blake@mcbride.name> wrote:
Has this been bug ticket number?
It wasn't. Just filed it as 224 and fixed it in r14019.
Thanks for the reports and tests!
Bye,
Erik.
On 07/23/2012 06:40 PM, Alessio Stalla wrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell <durward.mcdonell@jhuapl.edu> wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Yes. What I think is happening (and I could be wildly wrong) is that sublis is not loaded until it is called in the eval, where *read-base* has been reset to #x10. Then, when the fasl with sublis is autoloaded, it reads the FASL version number in base 16 and gets the wrong value, and fails. In fact, if you do the following, it works: CL-USER> (load "foo-bar.lisp") T CL-USER> (sublis '((x . y)) '(x)) (Y) CL-USER> (foo-bar-rb) (foo-bar '(foo)) (BAR) CL-USER> I assume this is because calling sublis is causing it to be autoloaded (with the expected *read-base*), and then it doesn't have to be loaded again when eval is called. -- Durward McDonell durward.mcdonell@jhuapl.edu 240-228-2690 (DC) 443-778-2690 (Balt.)
participants (4)
-
Alessio Stalla -
Blake McBride -
Durward McDonell -
Erik Huelsmann