Library fails to load libjnidispatch.so: temp file exists but UnsatisfiedLinkError is thrown

[Kaelin Laundry]

Hi,

I'm trying to use JNA but am running into some issues I can't quite track down.

First, the error itself along with debug logging:

Trying (via loadLibrary) jnidispatch

Looking in classpath from sun.misc.Launcher$AppClassLoader@1f96302 for /com/sun/jna/linux-arm/libjnidispatch.so

Found library resource at jar:file:/home/user/MyProgram.jar!/com/sun/jna/linux-arm/libjnidispatch.so

Trying /tmp/jna--1090444203/jna3359942142790415009.tmp

Error at <calling code>: ERROR Unhandled exception: java.lang.UnsatisfiedLinkError: /var/volatile/tmp/jna--1090444203/jna3359942142790415009.tmp: /var/volatile/tmp/jna--1090444203/jna3359942142790415009.tmp: internal error at [java.lang.ClassLoader$NativeLibrary.load(Native Method), java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929), java.lang.ClassLoader.loadLibrary(ClassLoader.java:1814), java.lang.Runtime.load0(Runtime.java:809), java.lang.System.load(System.java:1083), com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:947), com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:922), com.sun.jna.Native.<clinit>(Native.java:190), com.sun.jna.Pointer.<clinit>(Pointer.java:54), com.sun.jna.PointerType.<init>(PointerType.java:36), com.sun.jna.ptr.ByReference.<init>(ByReference.java:41), com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:33), ...]

 Additional context:

# ls -l -h -a -v /var/volatile/tmp/jna--1090444203/

total 108

-rw-r--r--    1 user group 104.8K Oct 22 00:22 jna112893891296521525.tmp

In other words, the temp file is being created with a reasonable size but something is preventing it from loading the SO. I'm not really sure how to proceed from there. I know that this is the call that fails: https://github.com/java-native-access/jna/blob/4.5.0/src/com/sun/jna/Native.java#L947. As far as I can tell, everything is in place as it should be, but the load fails and I don't know enough about Java's native library interfaces to debug it.

System info:

JNA 4.5.0

OS: Linux 4.1.15-rt17-ni-4.0.0f1 (NI's realtime kernel)

Processor: Xilinx Z-7020 All Programmable SoC dualcore ARM Cortex-A9

What can I do to resolve this?

Thanks!

[Kaelin Laundry]

Additional information:

$ file jna105277992838095344.tmp

jna105277992838095344.tmp: ELF 32-bit LSB  shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=a47a622459dc1becae58ba07965428f88ba5f2ae, not stripped

[Matthias Bläsing]

Hey Kaelin,

Am Samstag, den 21.10.2017, 13:44 -0700 schrieb Kaelin Laundry:
> Additional information:
>
> > $ file jna105277992838095344.tmp
> > jna105277992838095344.tmp: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=a47a622459dc1becae58ba07965428f88ba5f2ae, not stripped
>
> On Saturday, October 21, 2017 at 1:20:58 PM UTC-7, Kaelin Laundry wrote:
> > Hi,
> >
> > I'm trying to use JNA but am running into some issues I can't quite track down.
> >
> > First, the error itself along with debug logging:
> >

> > > [UnsatisfiedLinkError while loading libjnidispatch.so]

> >
> > Additional context:
> >
> > > # ls -l -h -a -v /var/volatile/tmp/jna--1090444203/
> > > total 108
> > > -rw-r--r-- 1 user group 104.8K Oct 22 00:22 jna112893891296521525.tmp
> >
> > In other words, the temp file is being created with a reasonable size but something is preventing it from loading the SO. I'm not really sure how to proceed from there. I know that this is the call that fails: https://github.com/java-native-access/jna/blob/4.5.0/src/com/sun/jna/Native.java#L947. As far as I can tell, everything is in place as it should be, but the load fails and I don't know enough about Java's native library interfaces to debug it.
> >
> > System info:
> >
> > JNA 4.5.0
> > OS: Linux 4.1.15-rt17-ni-4.0.0f1 (NI's realtime kernel)
> > Processor: Xilinx Z-7020 All Programmable SoC dualcore ARM Cortex-A9
> >
> > What can I do to resolve this?
> >

Please run

ldd -r jna105277992838095344.tmp

I suspect an issue with the libc.

Greetings

Matthias

[Kaelin Laundry]

Thanks for the suggestion! I'm realizing that I don't have ldd on this system; doesn't it ship with libc? How is this possible?

I tried this, if it's of any use -- my guess is that it isn't:

# /lib/ld-linux.so.3 --list /bin/bash

        libtinfo.so.5 => /lib/libtinfo.so.5 (0xb6f7b000)

        libdl.so.2 => /lib/libdl.so.2 (0xb6f70000)

        libc.so.6 => /lib/libc.so.6 (0xb6e3b000)

        /lib/ld-linux.so.3 (0x7f5c9000)

# /lib/ld-linux.so.3 --list jna2570864428599142251.tmp

jna2570864428599142251.tmp: error while loading shared libraries: jna2570864428599142251.tmp: cannot open shared object file

# /lib/ld-linux.so.3 --list /var/volatile/tmp/jna--1090444203/jna2570864428599142251.tmp

/var/volatile/tmp/jna--1090444203/jna2570864428599142251.tmp: error while loading shared libraries: /var/volatile/tmp/jna--1090444203/jna2570864428599142251.tmp: internal error

Note that they were both run on the same file contents, one of which was a copy of the other with the executable bit set.

I attached a copy of one of the files if it's useful (I have run JNA so many times I'm working with a bunch of differently-named files depending on which one I happened to copy, but they all have the same contents). Hopefully Google won't block the attachment if it realizes it's an executable.

Thanks!

[L Will Ahonen]

Hi,

Could you try running your app with ld_debug=all?

Something like ld_debug=all java -jar etc

BR,
Will

[Matthias Bläsing]

Hi Kaelin,

Am Sonntag, den 22.10.2017, 21:32 -0700 schrieb Kaelin Laundry:
> Thanks for the suggestion! I'm realizing that I don't have ldd on this system; doesn't it ship with libc? How is this possible?
>

I have a hunch: What linux distribution are you running on? JNA is
dynamicly linked against glibc - could it be, that there is a different
libc in use?

Greetings

Matthias

[Kaelin Laundry]

To quote an earlier email (sent from a different email account, not sure if Google forwarded it properly):

I do believe that the libc installed isn't glibc, it's the "vanilla" libc6 (the equivalent package for desktop Ubuntu is "libc6-i386"). The operating system is described in some detail here: http://www.ni.com/white-paper/14627/en/. It's a bit atypical as Linux distros go.

I just tried the LD_DEBUG variable. The results are included below (I grepped for what I figured would be most interesting, the output as a whole is quite long):

# eval "LD_DEBUG=all /usr/local/frc/JRE/bin/java -Djava.library.path=/usr/local/frc/lib/ -Djna.debug_load.jna=true -Djna.debug_load=true -Djnidispatch.preserve=true -jar /path/to/Program.jar" &> out.txt

# cat out.txt | grep jna

Looking in classpath from sun.misc.Launcher$AppClassLoader@1f96302 for /com/sun/jna/linux-arm/libjnidispatch.so

Found library resource at jar:file:/path/to/Program.jar!/com/sun/jna/linux-arm/libjnidispatch.so

Trying /tmp/jna-92668751/jna6027275766668271519.tmp

     18896:     file=/var/volatile/tmp/jna-92668751/jna6027275766668271519.tmp [0];  dynamically loaded by /usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

Error at <my code>: ERROR Unhandled exception: java.lang.UnsatisfiedLinkError: /var/volatile/tmp/jna-92668751/jna6027275766668271519.tmp: /var/volatile/tmp/jna-92668751/jna6027275766668271519.tmp: internal error at [java.lang.ClassLoader$NativeLibrary.load(Native Method), java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929), java.lang.ClassLoader.loadLibrary(ClassLoader.java:1814), java.lang.Runtime.load0(Runtime.java:809), java.lang.System.load(System.java:1083), com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:947), com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:922), com.sun.jna.Native.<clinit>(Native.java:190), com.sun.jna.Pointer.<clinit>(Pointer.java:54), com.sun.jna.PointerType.<init>(PointerType.java:36), com.sun.jna.ptr.ByReference.<init>(ByReference.java:41), com.sun.jna.ptr.IntByReference.<init>(IntByReference.java:33), ...]

# cat out.txt | grep dispatch

Trying (via loadLibrary) jnidispatch

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/java [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libpthread.so.0 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/../lib/arm/jli/libjli.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libdl.so.2 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libc.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/ld-linux.so.3 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libgcc_s.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libm.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libNiRioSrvEnumeratorPlugin.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/lib/libstdc++.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/librt.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libniriodevenum.so.1 [0]

     18896:     /usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_jnidispatch (fatal)

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/java [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libpthread.so.0 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/../lib/arm/jli/libjli.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libdl.so.2 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libc.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/ld-linux.so.3 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libgcc_s.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libm.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libNiRioSrvEnumeratorPlugin.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/lib/libstdc++.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/librt.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libniriodevenum.so.1 [0]

     18896:     /usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_jnidispatch (fatal)

Looking in classpath from sun.misc.Launcher$AppClassLoader@1f96302 for /com/sun/jna/linux-arm/libjnidispatch.so

Found library resource at jar:file:/path/to/Program.jar!/com/sun/jna/linux-arm/libjnidispatch.so

# cat out.txt | grep jni

Trying (via loadLibrary) jnidispatch

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/java [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libpthread.so.0 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/../lib/arm/jli/libjli.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libdl.so.2 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libc.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/ld-linux.so.3 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libgcc_s.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libm.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libNiRioSrvEnumeratorPlugin.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/lib/libstdc++.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/librt.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libniriodevenum.so.1 [0]

     18896:     /usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_jnidispatch (fatal)

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/java [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libpthread.so.0 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/bin/../lib/arm/jli/libjli.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libdl.so.2 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libc.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/ld-linux.so.3 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libgcc_s.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/libm.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libNiRioSrvEnumeratorPlugin.so [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/lib/libstdc++.so.6 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/lib/librt.so.1 [0]

     18896:     symbol=JNI_OnLoad_jnidispatch;  lookup in file=/usr/local/natinst/lib/libniriodevenum.so.1 [0]

     18896:     /usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_jnidispatch (fatal)

Looking in classpath from sun.misc.Launcher$AppClassLoader@1f96302 for /com/sun/jna/linux-arm/libjnidispatch.so

Found library resource at jar:file:/path/to/Program.jar!/com/sun/jna/linux-arm/libjnidispatch.so

Of potential note is this line:

/usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_jnidispatch (fatal)

Thanks!

[L Will Ahonen]

Hi,

It's likely it fails to load the JNA dll because it has dependencies that are unavailable. Out.txt has all the linker output from trying to load it, maybe you could add the whole file as an attachment?

Cheers,
Will

[Kaelin Laundry]

Sure! I uploaded the file here (it's larger than Google Groups is willing to handle as an attachment): https://gist.githubusercontent.com/WasabiFan/ffac2a6ad554824bc4e6ea9c07e726ec/raw/3b00ffc1f15f39f08678d0567748952df48a4601/out.txt .

Here's the excerpt from that file preceding the most interesting bit I saw:

Trying /tmp/jna-92668751/jna6027275766668271519.tmp

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/local/frc/JRE/bin/java [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/libpthread.so.0 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/local/frc/JRE/bin/../lib/arm/jli/libjli.so [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/libdl.so.2 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/libc.so.6 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/ld-linux.so.3 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/libgcc_s.so.1 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/local/frc/JRE/lib/arm/client/libjvm.so [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/libm.so.6 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/local/natinst/lib/libNiRioSrvEnumeratorPlugin.so [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/lib/libstdc++.so.6 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/lib/librt.so.1 [0]

     18896: symbol=JNI_OnLoad_6027275766668271519.;  lookup in file=/usr/local/natinst/lib/libniriodevenum.so.1 [0]

     18896: /usr/local/frc/JRE/bin/java: error: symbol lookup error: undefined symbol: JNI_OnLoad_6027275766668271519. (fatal)

I'm a bit confused by why it would be attempting to find a symbol which has a name change every run, but I assume that's part of the JNA runtime process.

[Timothy Wall]

The symbol suffix matches the temporary filename of the library (in a previous snippet it was "jnidispatch", which implies that run was using a non-temporary file).  

It's odd that the JVM would be appending a suffix to the JNI_OnLoad symbol (only "JNI_OnLoad" is defined in jnidispatch.dll).

Alter your test to load from an existing location rather than depending on the auto-extract to a temporary file, that will at least reduce the complexity of the problem.

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kaelin Laundry]

After doing a bit more digging I think I've solved my problem! It turns out that JNA was detecting my platform as "linux-arm" whereas the correct platform (and, by extension, build to load) was "linux-armel". My Java runtime returns "arm" for the "os.arch", which is where JNA was getting this value; I'm not sure where that logic in the JRE originates nor how it attempts to do the detection, but clearly there's a mismatch somewhere. I should've noticed that earlier!

Now, the next order of business: fix my native library mapping!

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.

[Matthias Bläsing]

Hey Kaelin,

Am Dienstag, den 24.10.2017, 20:36 -0700 schrieb Kaelin Laundry:
> After doing a bit more digging I think I've solved my problem! It
> turns out that JNA was detecting my platform as "linux-arm" whereas
> the correct platform (and, by extension, build to load) was "linux-
> armel". My Java runtime returns "arm" for the "os.arch", which is
> where JNA was getting this value; I'm not sure where that logic in
> the JRE originates nor how it attempts to do the detection, but
> clearly there's a mismatch somewhere. I should've noticed that
> earlier!

good find! This sounds like the problem that @kunkun26 is fixing in
this PR:

https://github.com/java-native-access/jna/pull/863

This is what happens:

The ARM architecture has flavors: arm-hardfloat and arm-softfloat. The
differ in the calling convention and that causes interoperability
problems.

Both are reported as os.arch = "arm", so a class "ELFAnalyser" was
introduced, that analyses the java binary to determine whether or not
it is hard- or softfloat. Based on that the prefix is choose to either
"arm" (hardfloat) or "armel" (softfloat).

The problem (that is fixed in the mentioned PR) is, that softfloat
calling convention can be indicated by a flag for softfloat, or by the
absense of the flag for hardfloat....

Greetings

Matthias