Linux 上的 Java System.loadLibrary 调用冻结

Question

我有一个非常小的 .so 文件（可在此处获得：https://docs.google.com/leaf?id=0B4MxFm-ACB3INjhkMjhlNzktYzkxYy00Zjk5LTk0Y2MtZDE2MWQ2MzY1OWUy&hl=en_US&authkey=CMrJguwN）

我正在尝试将其加载到 RHEL 上的 Java 中，而 Java main 只是冻结（没有错误或异常）。我在 LD_LIBRARY_PATH 上有包含 .so 文件的目录，所以我知道它实际上是在尝试加载它。

有什么办法可以解决这个问题吗？

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");
    }
}

编辑：

根据下面的帖子，我做了一个 strace.. 看起来它一遍又一遍地重复这个调用（虽然我不确定这意味着什么？）：

[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)

这里是完整版日志：https://docs.google.com/leaf?id=0B4MxFm-ACB3IYzdhZWIwNWEtYjUzMS00NGM5LWEzZjQtYzMzOWE3MWNhYWQ0&hl=en_US&authkey=CJ-Lv_wG

EDIT2：我也尝试使用 JNA 加载库：

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");
    }
}

这是输出.. 看起来非常相似：https://docs.google.com/leaf?id=0B4MxFm-ACB3IYzdhZWIwNWEtYjUzMS00NGM5LWEzZjQtYzMzOWE3MWNhYWQ0&hl=en_US&authkey=CJ-Lv_wG

编辑2：

这是我附加到进程的 gcore 输出。不知道这告诉我什么：

(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

Answer 1

如果我不得不猜测，我会说可能的罪魁祸首是共享对象的初始化代码。

获取 JVM 进程的核心转储（使用 gcore）或附加 gdb 以获取确切冻结位置的堆栈跟踪。

Answer 2

我通常在 gdb 之前尝试 strace（跟踪所有系统调用）。执行：

strace -f java SmallTester > logfile 2>&1

你会在logfile中得到很多信息，最后一部分是最有趣的。您会发现 jvm 进程正在寻找您的 TestAda.so 文件并查看它是否成功加载了 .so 文件。如果这不起作用，请恢复到 gdb。

Answer 3

查看 C++ 代码中的 JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) 函数。它可能有一个无限循环 :) 如果尚未定义，也可以尝试定义它。

有关JNI_OnLoad 的详细信息，请参阅here。