Question

Я пытаюсь связать (довольно большую) нативную библиотеку, написанную клиентом, в java код. Я написал этот упрощенный тестовый класс, который пытается загрузить библиотеку и тривиально вызвать нативный метод из библиотеки. Я также добавил некоторый отладочный код.

public class JniVtaTest {

  static {
    try {
      Process exec = Runtime.getRuntime().exec("ldd /usr/java/packages/lib/libvtajni.so");
      byte[] bytes = exec.getErrorStream().readAllBytes();
      System.out.println(new String(bytes));
      bytes = exec.getInputStream().readAllBytes();
      System.out.println(new String(bytes));
    } catch (IOException e) {
      e.printStackTrace();
    }
    String property = System.getProperty("java.library.path");
    System.out.println(property);

    // above code generates the debugging outpout shown below
    System.loadLibrary("vtajni");
  }

  // running with options:
  // -Djava.library.path="/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu" -verbose:jni -Xcheck:jni

  public static void main(String[] args) {
    new JniVtaTest().vtaAnalyze(args[0]);
  }

  private native String vtaAnalyze(String str);
}

Когда я запускаю вышеупомянутое с отмеченными параметрами, я получаю много выводов jvm о динамическом связывании классов jvm, а затем это:

    linux-vdso.so.1 (0x00007ffe2239d000)
    libiodbc.so.2 => /usr/lib/x86_64-linux-gnu/libiodbc.so.2 (0x00007ff6093b1000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff609028000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff608c8a000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff608a72000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff608681000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff60847d000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff62713d000)

11.0.5
/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu
Exception in thread "main" java.lang.UnsatisfiedLinkError: 'java.lang.String com.customer.jni.JniVtaTest.vtaAnalyze(java.lang.String)'
    at com.customer.jni.JniVtaTest.vtaAnalyze(Native Method)
    at com.customer.jni.JniVtaTest.main(JniVtaTest.java:26)

Кажется, что все библиотеки, загружаемые библиотекой, существуют:

gus@ns-l1:/usr/java/packages$ ls -al /usr/lib/x86_64-linux-gnu/libiodbc.so.2
lrwxrwxrwx 1 root root 18 Dec 12  2017 /usr/lib/x86_64-linux-gnu/libiodbc.so.2 -> libiodbc.so.2.1.20
gus@ns-l1:/usr/java/packages$ ls -al /usr/lib/x86_64-linux-gnu/libstdc++.so.6
lrwxrwxrwx 1 root root 19 Dec  4 09:45 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.25
gus@ns-l1:/usr/java/packages$ ls -al /lib/x86_64-linux-gnu/libm.so.6
lrwxrwxrwx 1 root root 12 Apr 16  2018 /lib/x86_64-linux-gnu/libm.so.6 -> libm-2.27.so
gus@ns-l1:/usr/java/packages$ ls -al /lib/x86_64-linux-gnu/libgcc_s.so.1
-rw-r--r-- 1 root root 96616 Dec  4 09:45 /lib/x86_64-linux-gnu/libgcc_s.so.1
gus@ns-l1:/usr/java/packages$ ls -al /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Apr 16  2018 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.27.so
gus@ns-l1:/usr/java/packages$ ls -al /lib/x86_64-linux-gnu/libdl.so.2
lrwxrwxrwx 1 root root 13 Apr 16  2018 /lib/x86_64-linux-gnu/libdl.so.2 -> libdl-2.27.so
gus@ns-l1:/usr/java/packages$ ls -al /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 32 Apr 16  2018 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so
gus@ns-l1:/usr/java/packages$

Все они также доступны через ldconfig -v -N, и я проверил, что ldconfig не находит библиотеки с буквами vta в этом, как это, так что я думаю, что я в безопасности от случайного совпадения имен:

ldconfig -v -N 2>&1 | grep vta
(no output shown)

Сама библиотека клиента явно загружена, потому что когда я отлаживаюсь, она не d ie в библиотеке загрузки, отладчик остановится на строке, вызывающей метод, и переход в этот код JVM показывает, что он нашел библиотеку с именем /usr/java/packages/lib/libvtajni.so и что он вводит для l oop сначала поиск Java_com_customer_jni_JniVtaTest_vtaAnalyze, а затем снова поиск Java_com_customer_jni_JniVtaTest_vtaAnalyze__Ljava_lang_String_2 (кажется, проверяется дважды для каждого из них)

    private static long findNative(ClassLoader loader, String entryName) {
        Map<String, NativeLibrary> libs =
            loader != null ? loader.nativeLibraries() : systemNativeLibraries();
        if (libs.isEmpty())
            return 0;

        // the native libraries map may be updated in another thread
        // when a native library is being loaded.  No symbol will be
        // searched from it yet.
        for (NativeLibrary lib : libs.values()) {
            long entry = lib.findEntry(entryName); <<<<< STOP DEBUGGER HERE
            if (entry != 0) return entry;
        }
        return 0;
    }

Файл заголовка, созданный с помощью javah com.customer.jni.JniVtaTest, выглядит следующим образом:

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_customer_jni_JniVtaTest */

#ifndef _Included_com_customer_jni_JniVtaTest
#define _Included_com_customer_jni_JniVtaTest
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     com_customer_jni_JniVtaTest
 * Method:    vtaAnalyze
 * Signature: (Ljava/lang/String;)Ljava/lang/String;
 */
JNIEXPORT jstring JNICALL Java_com_customer_jni_JniVtaTest_vtaAnalyze
  (JNIEnv *, jobject, jstring);

#ifdef __cplusplus
}
#endif
#endif

Метод в cpp файл выглядит так:

JNIEXPORT jstring JNICALL Java_com_customer_jni_JniVtaTest_vtaAnalyze
        (JNIEnv * env, jobject obj, jstring jInputText) {
    cout << "foo";

    // customer code...

    return  env->NewStringUTF(obuf);
}

И я никогда не вижу распечатанного foo, поэтому я не верю, что он находит метод, а затем происходит сбой внутри метода.

Полная версия JDK & system (ubuntu 18.04) info :

openjdk 11.0.5 2019-10-15 LTS
OpenJDK Runtime Environment Zulu11.35+15-CA (build 11.0.5+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.35+15-CA (build 11.0.5+10-LTS, mixed mode)

Linux ns-l1 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Часы поиска и чтения страниц, такие как https://developer.android.com/training/articles/perf-jni#faq: - Why-do-i-get-unsatisfiedlinkerror- и спец. c в https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#resolving -native-method-names заставили меня почесать голову.

Мой вопрос: почему я получаю эту ошибку? Что я пропустил.

Редактировать : согласно вопросу в комментариях я не нахожу символ с nm -D, но я действительно нахожу что-то с nm -A .. Теперь мне нужно выяснить, почему это так.

gus@ns-l1:~/clients/customer/code/vta_jni$ nm -A /usr/java/packages/lib/libvtajni.so | grep com_
/usr/java/packages/lib/libvtajni.so:00000000112a3d38 t _GLOBAL__sub_I__Z44Java_com_customer_jni_JniVtaTest_vtaAnalyzeP7JNIEnv_P8_jobjectP8_jstring
/usr/java/packages/lib/libvtajni.so:00000000112a388a T _Z44Java_com_customer_jni_JniVtaTest_vtaAnalyzeP7JNIEnv_P8_jobjectP8_jstring

Редактировать 2 : Заголовочный файл включен через ...

#include "com_customer_jni_JniVtaTest.h"

Изменить 3 : после изменения файла cmake для использования add_library(vtajni SHARED ... (и перекомпиляции кода клиента с помощью -fPIC) я теперь получаю следующее:

gus@ns-l1:~/clients/customer/code/vta_jni$ nm -D /usr/java/packages/lib/libvtajni.so | grep com_
00000000113587ba T _Z44Java_com_customer_jni_JniVtaTest_vtaAnalyzeP7JNIEnv_P8_jobjectP8_jstring

Но имя все еще искажено, предлагая вторая проблема с extern, как отмечено в комментариях ниже, но заголовок включен, как указано выше.

решено: искажение произошло из-за забытого редактирования отладки, которое закомментировало внешнюю часть файл заголовка в проекте C (но исходный сгенерированный файл в проекте java, который я вставил выше, все еще имел его), теперь я "успешно" заставил его напечатать

Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

that other guy · Answer 1 · 19 марта 2020

Чтобы функция работала, точное имя должно отображаться с заглавной буквы T в nm -D yourfile.so. Если это не так, вам нужно выяснить, почему.

Вот файл примера с тремя функциями, иллюстрирующими типичные проблемы:

extern "C" {
  void correct();
  extern void notInThisSo();
}
void correct() { }

void missingJniHeader() {}

static void* dummyUsage = (void*) &notInThisSo;

Вот вывод nm (начальные нули удалены) :

$ gcc foo.cc -shared -o foo.so && nm -D foo.so
000010f5 T correct                     # This works
         w __cxa_finalize
         w __gmon_start__
         w _ITM_deregisterTMCloneTable
         w _ITM_registerTMCloneTable
         U notInThisSo                 # This name is believed to be in another .so
000010fc T _Z16missingJniHeaderv       # This name is C++ mangled: missing extern "C" from header

Если в nm -D нет ничего похожего на ваше имя, отметьте nm -A yourfile.so:

$ cat bar.cc
extern "C" {
  __attribute((visibility("default"))) void visible() {}
  void not_visible() { }
}

$ gcc  -fvisibility=hidden bar.cc -shared -o bar.so  && nm -A bar.so
[...]
bar.so:000010fc t not_visible
bar.so:000010f5 T visible

Здесь вы можете увидеть not_visible со строчными буквами t, потому что сборка использовала -fvisibility=hidden, чтобы скрыть символ, и ничто явно не внесло его в белый список. JNI не может получить доступ к скрытым символам.

(Если nm -A дает nm: bar.so: no symbols, это означает, что библиотека удалена. Вы можете использовать nm -D для удаленных библиотек).

Unsatisfied Link Error - библиотека загружается, запись не найдена

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

Пожалуйста, войдите или зарегистрируйтесь что бы добавить комментарий.

Unsatisfied Link Error - библиотека загружается, запись не найдена

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

Пожалуйста, войдите или зарегистрируйтесь что бы добавить комментарий.

Похожие темы