Linux上的Java System.loadLibrary调用冻结 [英] Java System.loadLibrary call on Linux freezes

问题描述

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

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

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

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

编辑：

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

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)

这是日志的完整版本： http s：//docs.google.com/leaf？id = 0B4MxFm-ACB3IYzdhZWIwNWEtYjUzMS00NGM5LWEzZjQtYzMzOWE3MWNhYWQ0& hl = en_US& authkey = CJ-Lv_wG

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

EDIT2：我试过使用JNA加载库：

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

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

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

Edit2：

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

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

推荐答案

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

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

抓住y的核心转储我们的JVM进程（使用 gcore ）或附加 gdb 来获取堆栈跟踪的确切位置。

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

这篇关于Linux上的Java System.loadLibrary调用冻结的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！