0

I have a very small .so file (Available here: https://docs.google.com/leaf?id=0B4MxFm-ACB3INjhkMjhlNzktYzkxYy00Zjk5LTk0Y2MtZDE2MWQ2MzY1OWUy&hl=en_US&authkey=CMrJguwN)

I am trying to load this into Java on RHEL and the Java main just freezes (No errors or exceptions). I have the directory with the .so file on the LD_LIBRARY_PATH, so I know it's actually trying to load it.

Any ideas how I can troubleshoot this?

public class SmallTester {


    public static void main(String[] args){

        for(String s: System.getenv("LD_LIBRARY_PATH").split(":")){
            System.out.println(s);
        }

        System.loadLibrary("TestAda");

        System.out.println("Here");
    }
}

EDIT:

Based on the post below, I did a strace.. It looks like its repeating this call over and over again (I'm not sure what this means though?):

[pid 31464] clock_gettime(CLOCK_MONOTONIC, {3605675, 624255544}) = 0
[pid 31464] gettimeofday({1306417113, 168967}, NULL) = 0
[pid 31464] clock_gettime(CLOCK_MONOTONIC, {3605675, 624435576}) = 0
[pid 31464] clock_gettime(CLOCK_MONOTONIC, {3605675, 624518205}) = 0
[pid 31464] gettimeofday({1306417113, 169216}, NULL) = 0
[pid 31464] clock_gettime(CLOCK_REALTIME, {1306417113, 169306590}) = 0
[pid 31464] futex(0x88b3f04, FUTEX_WAIT_PRIVATE, 1, {0, 49909410}) = -1 ETIMEDOUT (Connection timed out)

Here is a full version of the log: https://docs.google.com/leaf?id=0B4MxFm-ACB3IYzdhZWIwNWEtYjUzMS00NGM5LWEzZjQtYzMzOWE3MWNhYWQ0&hl=en_US&authkey=CJ-Lv_wG

EDIT2: I tried to load the library with JNA as well:

public class SmallTesterJNA {

    public interface CLibrary extends Library {

      CLibrary INSTANCE1 = (CLibrary)
      Native.loadLibrary("TestAda", //  <<< our library goes here
                         CLibrary.class);

    }

    public static void main(String[] args){

        for(String s: System.getenv("LD_LIBRARY_PATH").split(":")){
            System.out.println(s);
        }

        System.loadLibrary(CLibrary.INSTANCE1.toString());

        System.out.println("Here");
    }
}

Here is the output.. It looks very similar: https://docs.google.com/leaf?id=0B4MxFm-ACB3IYzdhZWIwNWEtYjUzMS00NGM5LWEzZjQtYzMzOWE3MWNhYWQ0&hl=en_US&authkey=CJ-Lv_wG

Edit2:

Here is my gcore output attached to the process.. not sure what this is telling me:

(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb7fb26c0 (LWP 8326)]
[New Thread 0x7fa8eb90 (LWP 8340)]
[New Thread 0x7fe2db90 (LWP 8339)]
[New Thread 0x7fe7eb90 (LWP 8338)]
[New Thread 0x7feffb90 (LWP 8337)]
[New Thread 0x800afb90 (LWP 8336)]
[New Thread 0x80100b90 (LWP 8335)]
[New Thread 0x80351b90 (LWP 8334)]
[New Thread 0x803a2b90 (LWP 8333)]
[New Thread 0x80423b90 (LWP 8332)]
[New Thread 0x8066db90 (LWP 8331)]
[New Thread 0x806eeb90 (LWP 8330)]
[New Thread 0x8076fb90 (LWP 8329)]
[New Thread 0x807f0b90 (LWP 8328)]
[New Thread 0xb7474b90 (LWP 8327)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xb7fcd402 in __kernel_vsyscall ()
Saved corefile core.8326
mainstringargs
  • 13,563
  • 35
  • 109
  • 174

3 Answers3

1

If I had to guess, I'd say that a likely culprit is the shared object's initialization code.

Grab a core dump of your JVM process (using gcore) or attach gdb to get the stack trace of where exactly it's freezing.

NPE
  • 486,780
  • 108
  • 951
  • 1,012
1

I usually try strace before gdb (tracing all system calls). Execute:

strace -f java SmallTester > logfile 2>&1

You will get a lot of info in logfile, the last part is the most interesting. You will find the jvm process looking for your TestAda.so file and see if it successfully loaded the .so file. If this doesn't work, revert to gdb.

ivy
  • 5,539
  • 1
  • 34
  • 48
  • Can you take at the logfile above? Any idea what is going on? – mainstringargs May 26 '11 at 13:44
  • I don't think [pid 31464] is the problem, it's just a java thread waiting for something. As far as I can see, the jvm found your library in /adapts/ad/irad-c2/builds/mark/workspace/ASOC_M/mukul-branch/Omnyx/Projects/Test/buildLinux-i686/lib/libTestAda.so , this caused loading of libgnarl-6.2.so, libgnat-6.2.so and libgcc_s.so.1. After some initialization, the thread/process stopped (e.g. no syscalls were executed), so either it spins infinitely in initialization code (CPU to 100%?), or it blocks on some lock. – ivy May 26 '11 at 15:44
1

Have a look at your JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) function in your C++ code. It might have an infinite loop :) Also try defining this if it isn't defined already.

See here for details about JNI_OnLoad.

Chris Dennett
  • 22,412
  • 8
  • 58
  • 84
  • This is actually an Ada library.. Still trying to digest this post in terms of what I'm doing – mainstringargs May 26 '11 at 14:03
  • If you're using JNI, you can't just load an Ada library and expect to use it straight off. You need to interface it with JNI, which means creating functions which act as a bridge between Java and C++. It sounds like it's getting confused, maybe executing code DLL initialisation code which is giving these problems (maybe that code has a spinning loop). – Chris Dennett May 26 '11 at 14:10
  • If you want to do such a thing, you need to use JNA instead. But be aware that the initialisation code might still mess you up. – Chris Dennett May 26 '11 at 14:12
  • The weird part is that this exact same call works on Solaris.. (Without the JNI). I'm just trying to port this call to Linux and hitting this issue. – mainstringargs May 26 '11 at 14:19
  • This seems related to your problem: http://lists.globus.org/pipermail/gt-user/2010-February/008779.html – Chris Dennett May 26 '11 at 17:58