[armedbear-devel] abcl trunk build doesn't work for me
hi When I run ABCL built from trunk I get this error when I run it: ---- Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_21 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.072 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:802) at org.armedbear.lisp.Lisp.error(Lisp.java:380) at org.armedbear.lisp.Load.loadSystemFile(Load.java:276) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:703) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:550) at org.armedbear.lisp.Lisp.eval(Lisp.java:515) at org.armedbear.lisp.Load.loadStream(Load.java:570) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:538) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:428) at org.armedbear.lisp.Load.loadSystemFile(Load.java:327) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:679) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads' in boot classpath. ---- I tried both version from SVN and from Mark's (?) hg repo, upgraded OpenJDK to 1.6.0_21, upgraded ant from 1.7.1 to 1.8.0 (that's top version I can get via package manager for Ubuntu 10.04). I was able to build and run ABCL 1.0.1. I noticed a bug on abcl 1.0.1: in certain rather contrived code return-from was ignored, i.e. evaluation continued as if it wasn't called. And was going to check whether it's present in the latest devel version before investigating it further.
Alex Mizrahi <alex.mizrahi@gmail.com> writes:
hi
When I run ABCL built from trunk I get this error when I run it:
---- Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_21 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 1.072 seconds. org.armedbear.lisp.IntegrityError [...]
I got not much to add, except it works here from a fresh checkout: Armed Bear Common Lisp 1.1.0-dev Java 1.6.0_31 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.726 seconds. Startup completed in 2.554 seconds. Loading /Users/rudi/.abclrc completed in 11.705 seconds. Type ":help" for a list of available commands. CL-USER(1): Rudi
Ok, this turned out to be a problem with build -- it looks like new ABCL version has more stuff, and jvm tried to open too many files. I had to rise nofile ulimit to 8192. I didn't notice this from start because build process didn't check errors during compiling with abcl stage and proceeded to create jar file regardless. It said that build was successful so I didn't check error messages which scrolled away by that time.
On Sun, May 27, 2012 at 5:41 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
Ok, this turned out to be a problem with build -- it looks like new ABCL version has more stuff, and jvm tried to open too many files. I had to rise nofile ulimit to 8192.
I didn't notice this from start because build process didn't check errors during compiling with abcl stage and proceeded to create jar file regardless. It said that build was successful so I didn't check error messages which scrolled away by that time.
Too many open files occurred to me too a while ago. Usually doing an incremental build after the failed one works. But I don't get why all those files need to be opened at once; I thought it was a leak. -- 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
Yes, it is a leak. compile-file.lisp, function verify-load: (when (= 0 (file-length (open classfile :direction :input))) fd is opened and never closed. (Until GC, I guess.) It is called for every cls file compiler produces. Bug was introduced in revision 13912.
Hi Alex, On Sun, May 27, 2012 at 9:35 PM, Alex Mizrahi <alex.mizrahi@gmail.com>wrote:
Yes, it is a leak. compile-file.lisp, function verify-load:
(when (= 0 (file-length (open classfile :direction :input)))
fd is opened and never closed. (Until GC, I guess.) It is called for every cls file compiler produces.
Bug was introduced in revision 13912.
I think this is an easy one. I can probably get it fixed in a few minutes (but rebuilding will take me a while); expect a fix forth coming in 30 minutes. Bye, Erik.
Fix committed in r13948. Please verify and confirm. Thanks for your report and research! Bye, Erik. On Sun, May 27, 2012 at 9:39 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
Hi Alex,
On Sun, May 27, 2012 at 9:35 PM, Alex Mizrahi <alex.mizrahi@gmail.com>wrote:
Yes, it is a leak. compile-file.lisp, function verify-load:
(when (= 0 (file-length (open classfile :direction :input)))
fd is opened and never closed. (Until GC, I guess.) It is called for every cls file compiler produces.
Bug was introduced in revision 13912.
I think this is an easy one. I can probably get it fixed in a few minutes (but rebuilding will take me a while); expect a fix forth coming in 30 minutes.
Bye,
Erik.
participants (4)
-
Alessio Stalla -
Alex Mizrahi -
Erik Huelsmann -
Rudi Schlatte