JNA 3.4.0 : JVM Crash, Linux x64 with Tomcat

[Vico]

Hello everybody,

I'm not a Linux x64 specialist, so maybe somebody can give me some hints in order to understand where the problem is.

I have a Tomcat 7 server on Red Hat Enterprise Linux Server release 6.2 (x64 amd), native .so files are loaded at startup with Spring api.

In short, JVM crashes when I invoke a method from the bean implementing the JNA interface, here is the backtrace :

INFO: Server startup in 35212 ms

*** glibc detected *** /usr/java/default/bin/java: double free or corruption (out): 0x00007f6991212af0 ***

======= Backtrace: =========

/lib64/libc.so.6[0x3499674c06]

/lib64/libdl.so.2[0x3a21a01505]

/lib64/libdl.so.2(dlsym+0x4a)[0x3a21a0109a]

/usr/share/tomcat70/temp/jna/jna1768815498719831606.tmp(Java_com_sun_jna_Native_findSymbol+0x4d)[0x7f69fb78d28d]

[0x7f6a5b071b55]

======= Memory map: ========

40000000-40009000 r-xp 00000000 fd:00 1315907                            /usr/java/jdk1.6.0_29/bin/java

40108000-4010a000 rwxp 00008000 fd:00 1315907                            /usr/java/jdk1.6.0_29/bin/java

41dc4000-41de5000 rwxp 00000000 00:00 0                                  [heap]

b0000000-e0970000 rwxp 00000000 00:00 0

e0970000-e3800000 ---p 00000000 00:00 0

e3800000-eaab0000 rwxp 00000000 00:00 0

eaab0000-ff8f0000 rwxp 00000000 00:00 0

ff8f0000-100000000 ---p 00000000 00:00 0

[more...]

When debugging Tomcat with eclipse, I see this code in Function.java (JNA 3.4.0), line 176 :

try {

            this.peer = library.getSymbolAddress(functionName);

        }

        catch(UnsatisfiedLinkError e) {

            throw new UnsatisfiedLinkError("Error looking up function '" 

                                           + functionName + "': " 

                                           + e.getMessage());

        }

The catch block is never reached and JVM crashes when calling "library.getSymbolAdress".

If I run the same JNA code in a JUnit test (the same Linux machine, but outside Tomcat), it works.

Does anybody has any idea ?

Thanks in advance :)

[Mayur Thakare]

 Did you get solution of this problem? I am facing similar issue.
What is the kernel version? Is it 2.6.32-220? If yes, consider downgrading your kernel to 2.6.32-131.17.1 or below.
Refer this link -

http://www-01.ibm.com/support/docview.wss?uid=swg21579918

This is what I have observed, but I am not 100% sure.

[Timothy Wall]

Try using an already-unpacked libjnidispatch.so of a known version, so that JNA/tomcat isn't unpacking a new shared lib every time, then ensure that tomcat loads JNA once and only once (rather than loading and unloading based on individual module requirements).

That won't necessarily fix your problem, but it will reduce the number of variables in the situation.