brettwooldridge/NuProcess

jdk-10.0.1/lib/libjava.so: undefined symbol: Java_java_lang_UNIXProcess_forkAndExec

fanf opened this issue · 8 comments

fanf commented

With NuProcess version 1.2.3, I get the following error when I try to run my tests with Open JDK 10.0.1 under linux:

UNIXProcess_forkAndExec': /home/fanf/java/jdk-10.0.1/lib/libjava.so: undefined symbol: Java_java_lang_UNIXProcess_forkAndExec
at com.sun.jna.Function.(Function.java:245)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:566)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:542)
at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:528)
at com.sun.jna.Native.register(Native.java:1777)
at com.sun.jna.Native.register(Native.java:1370)
at com.zaxxer.nuprocess.internal.LibJava8.(LibJava8.java:36)
at com.zaxxer.nuprocess.internal.BasePosixProcess.start(BasePosixProcess.java:163)
at com.zaxxer.nuprocess.linux.LinProcessFactory.createProcess(LinProcessFactory.java:40)
at com.zaxxer.nuprocess.NuProcessBuilder.start(NuProcessBuilder.java:266)
at com.normation.rudder.hooks.RunNuCommand$.run(RunNuCommand.scala:153)

I didn't found other reference to problem with OpenJDK 10 (appart #87 but it seems different). It used to work with 1.1.x branch.
Do you need more information to reproduce?

slandelle commented

As of Java 10, UNIXProcess was merged into ProcessImpl: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/98eb910c9a97

Neoware commented

@brettwooldridge Hi ! If you can check my pull request :)

slandelle commented

Basically, it seems that Azul has back-ported into their Java 8 build the OpenJDK 10 change I mentioned above.
The PR:

  • fixes Constants#JVM_MAJOR_VERSION that was broken with Java9+ and was actually unused
  • renames the new stategy that was introduced for Azul as it's actually generic for Java10+
  • uses this strategy when running on Azul or Java10+
fanf commented

@brettwooldridge @slandelle @Neoware seems great (but I know nothing about nuprocess internals)

slandelle commented

We ended up deploying into our private repo until this gets merged and released.

bturner commented

@slandelle, @brettwooldridge,

Basically, it seems that Azul has back-ported into their Java 8 build the OpenJDK 10 change I mentioned above.

I'm curious about this, because it doesn't appear to be the case from what I can see. Were you looking at Zing when you found this, or Zulu? The original issue for Zulu, #87, was about Zulu JDK 10.2+3-jdk10.0.1, which makes me wonder if it was a Java 10 issue all along, and Zulu was a red herring.

Using the latest Azul Zulu release for Java 8:

$ ./java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (Zulu 8.44.0.9-CA-linux64) (build 1.8.0_242-b20)
OpenJDK 64-Bit Server VM (Zulu 8.44.0.9-CA-linux64) (build 25.242-b20, mixed mode)

Attempting to run processes fails with:

java.lang.UnsatisfiedLinkError: Error looking up function 'Java_java_lang_ProcessImpl_forkAndExec': /home/bturner/Development/jvm/zulu8.44.0.9-ca-jdk8.0.242-linux_x64/jre/lib/amd64/libjava.so: undefined symbol: Java_java_lang_ProcessImpl_forkAndExec
	at com.sun.jna.Function.<init>(Function.java:251)
	at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:594)
	at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:570)
	at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:556)
	at com.sun.jna.Native.register(Native.java:1846)
	at com.sun.jna.Native.register(Native.java:1447)
	at com.zaxxer.nuprocess.internal.LibJava10.<clinit>(LibJava10.java:37)
	at com.zaxxer.nuprocess.linux.LinuxProcess.prepareProcess(LinuxProcess.java:153)
	at com.zaxxer.nuprocess.linux.LinuxProcess.start(LinuxProcess.java:70)
	at com.zaxxer.nuprocess.linux.LinProcessFactory.createProcess(LinProcessFactory.java:40)
	at com.zaxxer.nuprocess.NuProcessBuilder.start(NuProcessBuilder.java:259)

If I comment out the isAzul check in LinuxProcess, such that it runs the "normal" Java 8 path with Java_java_lang_UNIXProcess_forkAndExec, then everything appears to work without issue.

I know it's been quite a while since this issue was closed, but does anyone happen to recall whether the change was tested against Azul Zulu for Java 8, or just 10+?

Neoware commented

Hey @bturner,

If you look at the commit we made back then, we didn't add the Zulu special case, it was already there, and we simply add the same logic for "regular" Java 10+ because that was this support that interested us.

As @slandelle said, "it seems" that Azul backported it, because that's what we ended up thinking from looking at the code that consisted only in a global isAzul. We didn't test on Azul for this issue, that was not our point.

But now, when I look at this commit f5c4194 and the #87 which introduced the problem for Azul 8, It seems that a if (Java 10+) is the only thing that was required all along, you're right :)