run-program issues with OpenJDK 11
It appears that java.lang.UNIXProcess was removed in OpenJDK 9 or thereabouts, assuming I'm interpreting https://github.com/openjdk/jdk/commit/aa6b19f38ee4dc69cac664d1211bff0e69b31f... correctly (/definitely/ not a Java developer here...). This seems to make run-program unusable when using prebuilt jars on recent JREs. Using the prebuilt 1.7.0 release and OpenJDK 11, I get the errors shown in prebuilt-openjdk11.txt (attached). If compiling using OpenJDK 11, run-program seems usable, but any attempt to get the PID of a process gives the error in from-source-openjdk11.txt (attached). -Eric VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.0 Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.198 seconds. Startup completed in 1.107 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil) Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Autoload.effectiveLoad(Autoload.java:110) at org.armedbear.lisp.Autoload.load(Autoload.java:147) at org.armedbear.lisp.Lisp.eval(Lisp.java:537) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3743) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.armedbear.lisp.Go Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_60 from org.armedbear.lisp.Pathname@49bd2fd0 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (exit) VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.1-dev Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.205 seconds. Startup completed in 1.224 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil :wait nil) #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl Process[pid=125, exitValue=0] {1E464845}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(2): (sys:process-pid *) #<THREAD "interpreter" {7278E1D6}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): 0 CL-USER(4): (exit)
On Jun 29, 2020, at 01:13, Eric Timmons <etimmons@mit.edu> wrote:
It appears that java.lang.UNIXProcess was removed in OpenJDK 9 or thereabouts, assuming I'm interpreting https://github.com/openjdk/jdk/commit/aa6b19f38ee4dc69cac664d1211bff0e69b31f... correctly (/definitely/ not a Java developer here...).
This seems to make run-program unusable when using prebuilt jars on recent JREs. Using the prebuilt 1.7.0 release and OpenJDK 11, I get the errors shown in prebuilt-openjdk11.txt (attached).
Hmmm. I can’t seem to confirm under abcl-bin-1.7.0/openjdk11/linux. CL-USER> (sys:run-program "ls" nil) #S(SYSTEM>:PROCESS :JPROCESS #<java.lang.ProcessImpl Process[pid=622, exitValue="no\ t .... {78663B49}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STR\ EAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER> (swank-backend:getpid) 32418 5 CL-USER> (lisp-implementation-version) "1.7.0" "OpenJDK_64-Bit_Server_VM-AdoptOpenJDK-11.0.7+10" "amd64-Linux-4.19.0-9-amd64”
to get the PID of a process gives the error in from-source-openjdk11.txt (attached).
[…] The (SWANK-BACKEND:GETPID) thunks down to the implementation where available, as is the case in abcl-1.4.0 (??) onwards. […]
Armed Bear Common Lisp 1.7.1-dev Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.205 seconds. Startup completed in 1.224 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil :wait nil) #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl Process[pid=125, exitValue=0] {1E464845}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(2): (sys:process-pid *) #<THREAD "interpreter" {7278E1D6}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess
[…] What are the values returned for LISP-IMPLEMENTATION-VERSION where you encountering the error? You aren’t trying to get a java.lang.UNIXProcess under Windows by any chance? -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Mark Evenson <evenson@panix.com> writes:
Hmmm. I can’t seem to confirm under abcl-bin-1.7.0/openjdk11/linux.
I'll be honest, I thought I was going crazy at first! It seemed weird that things like this would break things like this between versions. I'd love it if there's some other explanation! [...]
What are the values returned for LISP-IMPLEMENTATION-VERSION where you encountering the error?
You aren’t trying to get a java.lang.UNIXProcess under Windows by any chance?
Nope, I'm running on Gentoo with kernel 5.4.45 and in Docker containers running on that computer. I've attached a tarball containing the Docker build context and some scripts I used to test this. The build-images script will build Docker images using the ABCL 1.7.0 jar running with Buster's default JRE (11), Stretch's default JRE (8), the JRE in the openjdk:11-buster image, and the JRE in the openjdk:8-buster image. The test-run-program script will try to start a child process using each of the images. The first value of LISP-IMPLEMENTATION-VERSION is always "1.7.0" and the third is always "amd64-Linux-5.4.45-gentoo". I get the errors when the second value is one of: + "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" (docker label debian-buster) + "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-11.0.7+10" (docker label opendjk-11-buster) + "OpenJDK_64-Bit_Server_VM-AdoptOpenJDK-11.0.7+10" (native) I don't get errors when the second value is one of: + "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.8.0_252-8u252-b09-1~deb9u1-b09" (docker label debian-stretch) + "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.8.0_252-b09" (docker label openjdk-8-buster) + "OpenJDK_64-Bit_Server_VM-AdoptOpenJDK-1.8.0_252-b09" (native) I've also attached the full output of running the test-run-program script from the tarball (after build-images has already been run). -Eric ############################################################################### # Running test on debian-buster ############################################################################### Armed Bear Common Lisp 1.7.0 Java 11.0.7 Debian OpenJDK 64-Bit Server VM Low-level initialization completed in 0.211 seconds. Startup completed in 1.098 seconds. ("1.7.0" "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" "amd64-Linux-5.4.45-gentoo") org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: Class not found: java.lang.UNIXProcess at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:569) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.debug_6.execute(debug.lisp:105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.debug_7.execute(debug.lisp:114) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Java.classForName(Java.java:1358) at org.armedbear.lisp.Java.javaClass(Java.java:1391) at org.armedbear.lisp.Java$pf_jclass.execute(Java.java:153) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Stream.readSharpDot(Stream.java:922) at org.armedbear.lisp.FaslReader$7.execute(FaslReader.java:130) at org.armedbear.lisp.Stream.readDispatchChar(Stream.java:814) at org.armedbear.lisp.FaslReader$4.execute(FaslReader.java:91) at org.armedbear.lisp.Stream.processChar(Stream.java:589) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:558) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:567) at org.armedbear.lisp.Stream.read(Stream.java:501) at org.armedbear.lisp.Lisp.readObjectFromReader(Lisp.java:1328) at org.armedbear.lisp.Lisp.readObjectFromString(Lisp.java:1305) at org.armedbear.lisp.run_program_60.<clinit>(run-program.lisp) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Autoload.effectiveLoad(Autoload.java:110) at org.armedbear.lisp.Autoload.load(Autoload.java:147) at org.armedbear.lisp.Lisp.eval(Lisp.java:537) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:570) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:614) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:303) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.base/java.lang.Thread.run(Thread.java:834) Caught ERROR while processing --eval option "(print (sys:run-program "ls" nil))": Compiled function can't be loaded: org.armedbear.lisp.run_program_60 from org.armedbear.lisp.Pathname@6b38bb10 ############################################################################### # Running test on debian-stretch ############################################################################### Armed Bear Common Lisp 1.7.0 Java 1.8.0_252 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.254 seconds. Startup completed in 1.199 seconds. ("1.7.0" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.8.0_252-8u252-b09-1~deb9u1-b09" "amd64-Linux-5.4.45-gentoo") #S(SYSTEM:PROCESS :JPROCESS #<java.lang.UNIXProcess java.lang.UNIXProcess@381c96f5 {690E5CE5}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) ############################################################################### # Running test on openjdk-11-buster ############################################################################### Armed Bear Common Lisp 1.7.0 Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.218 seconds. Startup completed in 1.209 seconds. ("1.7.0" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-11.0.7+10" "amd64-Linux-5.4.45-gentoo") org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition: Class not found: java.lang.UNIXProcess at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:569) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.debug_6.execute(debug.lisp:105) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.LispThread.execute(LispThread.java:851) at org.armedbear.lisp.debug_7.execute(debug.lisp:114) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.signal_2.execute(signal.lisp:63) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Java.classForName(Java.java:1358) at org.armedbear.lisp.Java.javaClass(Java.java:1391) at org.armedbear.lisp.Java$pf_jclass.execute(Java.java:153) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Stream.readSharpDot(Stream.java:922) at org.armedbear.lisp.FaslReader$7.execute(FaslReader.java:130) at org.armedbear.lisp.Stream.readDispatchChar(Stream.java:814) at org.armedbear.lisp.FaslReader$4.execute(FaslReader.java:91) at org.armedbear.lisp.Stream.processChar(Stream.java:589) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:558) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:567) at org.armedbear.lisp.Stream.read(Stream.java:501) at org.armedbear.lisp.Lisp.readObjectFromReader(Lisp.java:1328) at org.armedbear.lisp.Lisp.readObjectFromString(Lisp.java:1305) at org.armedbear.lisp.run_program_60.<clinit>(run-program.lisp) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Autoload.effectiveLoad(Autoload.java:110) at org.armedbear.lisp.Autoload.load(Autoload.java:147) at org.armedbear.lisp.Lisp.eval(Lisp.java:537) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:570) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:614) at org.armedbear.lisp.Interpreter.postprocessCommandLineArguments(Interpreter.java:303) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:110) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.base/java.lang.Thread.run(Thread.java:834) Caught ERROR while processing --eval option "(print (sys:run-program "ls" nil))": Compiled function can't be loaded: org.armedbear.lisp.run_program_60 from org.armedbear.lisp.Pathname@706df0f0 ############################################################################### # Running test on openjdk-8-buster ############################################################################### Armed Bear Common Lisp 1.7.0 Java 1.8.0_252 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.259 seconds. Startup completed in 1.124 seconds. ("1.7.0" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.8.0_252-b09" "amd64-Linux-5.4.45-gentoo") #S(SYSTEM:PROCESS :JPROCESS #<java.lang.UNIXProcess java.lang.UNIXProcess@3ab95c2d {588DCBFE}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM))
I just tested this on a fresh Debian Buster VM (to rule out anything weird from my environment) with openjdk-11-jdk-headless and ABCL 1.7.1 and ended up with the same results: + The prebuilt jar is unable to use sys:run-program at all. + When built from source, sys:run-program works, but sys:process-pid does not. lisp-implementation-version: "1.7.1" "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" "amd64-Linux-4.19.0.9-amd64" Mark: I just realized that your use of swank-backend:getpid doesn't match what I was trying to do. Swank's getpid gets the PID of the current process, but I was trying to get the PID of a process started with (sys:run-program ... :wait nil) using sys:process-pid. -Eric
On Jul 22, 2020, at 21:03, Eric Timmons <etimmons@mit.edu> wrote:
I just tested this on a fresh Debian Buster VM (to rule out anything weird from my environment) with openjdk-11-jdk-headless and ABCL 1.7.1 and ended up with the same results:
+ The prebuilt jar is unable to use sys:run-program at all.
+ When built from source, sys:run-program works, but sys:process-pid does not.
lisp-implementation-version:
"1.7.1" "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" "amd64-Linux-4.19.0.9-amd64"
Mark: I just realized that your use of swank-backend:getpid doesn't match what I was trying to do. Swank's getpid gets the PID of the current process, but I was trying to get the PID of a process started with (sys:run-program ... :wait nil) using sys:process-pid.
-Eric
Finally able to confirm the failure of SYS:RUN-PROGRAM when SLIME is *not* used. Debugging further… <https://abcl.org/trac/ticket/470> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Heh, I was just about to send the same error... On a pixelbook vm openjdk 11.0.8 2020-07-14 On Fri, Jul 24, 2020 at 3:53 AM Mark Evenson <evenson@panix.com> wrote:
On Jul 22, 2020, at 21:03, Eric Timmons <etimmons@mit.edu> wrote:
I just tested this on a fresh Debian Buster VM (to rule out anything weird from my environment) with openjdk-11-jdk-headless and ABCL 1.7.1 and ended up with the same results:
+ The prebuilt jar is unable to use sys:run-program at all.
+ When built from source, sys:run-program works, but sys:process-pid does not.
lisp-implementation-version:
"1.7.1" "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" "amd64-Linux-4.19.0.9-amd64"
Mark: I just realized that your use of swank-backend:getpid doesn't match what I was trying to do. Swank's getpid gets the PID of the current process, but I was trying to get the PID of a process started with (sys:run-program ... :wait nil) using sys:process-pid.
-Eric
Finally able to confirm the failure of SYS:RUN-PROGRAM when SLIME is *not* used.
Debugging further…
<https://abcl.org/trac/ticket/470>
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Note: I'm using the ABCL binary from https://common-lisp.net/project/armedbear/ abcl-bin-1.7.1.tar.gz <https://common-lisp.net/project/armedbear/releases/1.7.1/abcl-bin-1.7.1.tar.gz> On Mon, Jul 27, 2020 at 11:14 PM Jonathan Godbout <jgodbou@gmail.com> wrote:
Heh, I was just about to send the same error... On a pixelbook vm openjdk 11.0.8 2020-07-14
On Fri, Jul 24, 2020 at 3:53 AM Mark Evenson <evenson@panix.com> wrote:
On Jul 22, 2020, at 21:03, Eric Timmons <etimmons@mit.edu> wrote:
I just tested this on a fresh Debian Buster VM (to rule out anything weird from my environment) with openjdk-11-jdk-headless and ABCL 1.7.1 and ended up with the same results:
+ The prebuilt jar is unable to use sys:run-program at all.
+ When built from source, sys:run-program works, but sys:process-pid does not.
lisp-implementation-version:
"1.7.1" "OpenJDK_64-Bit_Server_VM-Debian-11.0.7+10-post-Debian-3deb10u1" "amd64-Linux-4.19.0.9-amd64"
Mark: I just realized that your use of swank-backend:getpid doesn't match what I was trying to do. Swank's getpid gets the PID of the current process, but I was trying to get the PID of a process started with (sys:run-program ... :wait nil) using sys:process-pid.
-Eric
Finally able to confirm the failure of SYS:RUN-PROGRAM when SLIME is *not* used.
Debugging further…
<https://abcl.org/trac/ticket/470>
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
I am finally able to report some progress on understanding the problem, and provide a workaround. This bug occurs when the system compiled with openjdk8 is run under the openjdk11 runtime. Inconsistently, the abcl-1.7.0 binaries were compiled with openjdk11 while the abcl-1.7.1 binaries were compiled with openjdk8. In openjdk11, the java.lang.UNIXProcess class has been replaced with java.lang.ProcessImpl, so our code needs to conditionally find the pid of a given process based on the platform that the ABCL finds itself running upon. As a workaround until we fix and release the next version of ABCL, one may get sys:run-program running as long as one doesn't try to get the pid via first running the following code which is sufficient to load sys:run-program: (ignore-errors (sys:run-program "true" nil)) An easy fix for users of the abcl-1.7.1 binaries under openjdk11 would be to place such code in <file:~/.abclrc>. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
I’ve made some recents commits that should be part of abcl-1.7.2 (real soon noon).
On Jul 24, 2020, at 09:52, Mark Evenson <evenson@panix.com> wrote:
[…]
Debugging further…
[…] Issues with openjdk11 not able to invoke SYS:RUN-PROGRAM fixed with <https://abcl.org/trac/changeset/15358>. Additionally I did some light testing over running the implementation compiled with openjdk11 on java8 implementations. This shook out [some bugs with the compiler][2], as the the openjdk11 compiler optimizesoptimizes the call to java.nio.Buffer.flip() in to be directly on the java.nio.ByteBuffer type. We fixed other instances of java.nio.Buffer interfaces to the point of being able to run the ANSI-TEST suite. I was able to get around this with some fairly ugly looking casts. But it seems to work… // capacity = buffer.limit(); ==> capacity = ((java.nio.Buffer)buffer).limit(); [1]: <https://github.com/armedbear/abcl/commit/7021a905222c2b743422b607409233771e4ed623> [2]: <https://github.com/armedbear/abcl/commit/4786b62113d6da9cf358b25fe23ed05e8e05e6da> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
participants (3)
-
Eric Timmons -
Jonathan Godbout -
Mark Evenson