HP-UX: libstd_v2 в трассировке стека кода JNI, скомпилированного с g ++

Question

uname -mr: B.11.23 ia64

g ++ - версия: g ++ (GCC) 4.4.0

Java-версия:

Java (TM) SE Runtime Environment (сборка 1.6.0.06-jinteg_20_jan_2010_05_50-b00) Серверная виртуальная машина Java HotSpot (TM) (сборка 14.3-b01-jre1.6.0.06-rc1, смешанный режим)

Я пытаюсь запустить приложение Java, которое использует JNI. Это происходит сбой внутри кода JNI со следующей (сокращенной) трассировкой стека:

(0) 0xc0000000249353e0 VMError::report_and_die{_ZN7VMError14report_and_dieEv} + 0x440 at /CLO/Components/JAVA_HOTSPOT/Src/src/share/vm/utilities/vmError.cpp:738 [/opt/java6/jre/lib/IA64W/server/libjvm.so]
(1) 0xc000000024559240 os::Hpux::JVM_handle_hpux_signal{_ZN2os4Hpux22JVM_handle_hpux_signalEiP9
__siginfoPvi} + 0x760 at /CLO/Components/JAVA_HOTSPOT/Src/src/os_cpu/hp-ux_ia64/vm/os_hp-ux_ia64.cpp:1051 [/opt/java6/jre/lib/IA64W/server/libjvm.so]
(2) 0xc0000000245331c0 os::Hpux::signalHandler{_ZN2os4Hpux13signalHandlerEiP9__siginfoPv} + 0x80 at /CLO/Components/JAVA_HOTSPOT/Src/src/os/hp-ux/vm/os_hp-ux.cpp:4295 [/opt/java6/jre/lib/IA64W/server/libjvm.so]
(3) 0xe00000010e002620 ---- Signal 11 (SIGSEGV) delivered ----
(4) 0xc0000000000d2d20 __pthread_mutex_lock + 0x400 at /ux/core/libs/threadslibs/src/common/pthreads/mutex.c:3895 [/usr/lib/hpux64/libpthread.so.1]
(5) 0xc000000000342e90 __thread_mutex_lock + 0xb0 at ../../../../../core/libs/libc/shared_em_64/../core/threads/wrappers1.c:273 [/usr/lib/hpux64/libc.so.1]
(6) 0xc00000000177dff0 _HPMutexWrapper::lock{_ZN15_HPMutexWrapper4lockEPv} + 0x90 [/usr/lib/hpux64/libstd_v2.so.1]
(7) 0xc0000000017e9960 std::basic_string,std::allocator{_ZNSsC1ERKSs} + 0x80 [/usr/lib/hpux64/libstd_v2.so.1]
(8) 0xc000000008fd9fe0 JniString::str{_ZNK9JniString3strEv} + 0x50 at eg_handler_jni.cxx:50 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0]
(9) 0xc000000008fd7060 pt_efacec_se_aut_frk_cmp_registry_REGHandler::getKey{_ZN44pt_efacec_se_aut_frk_cmp_registry_REGHandler6getKeyEP8_jstringi} + 0xa0 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0]
(10) 0xc000000008fd17f0 Java_pt_efacec_se_aut_frk_cmp_registry_REGHandler_getKey__Ljava_lang_String_2I + 0xa0 [/soft/bus-7_0/lib/libbus_registry_jni.so.7.0.0]
(11) 0x9fffffffdf400ed0

Internal error (-3) while unwinding stack [/CLO/Components/JAVA_HOTSPOT/Src/src/os_cpu/hp-ux_ia64/vm/thread_hp-ux_ia64.cpp:142] 

Этот код JNI и зависимости компилируются с использованием g ++, являются многопоточными и 64-битными (-pthread -mlp64 -shared -fPIC). Переменная среды LD_LIBRARY_PATH задает расположение зависимостей, и запуск ldd в общих библиотеках JNI находит их все:

ldd libbus_registry_jni.so:

libefa-d.so.7 => /soft/bus-7_0/lib/libefa-d.so.7
libbus_registry-d.so.7 => /soft/bus-7_0/lib/libbus_registry-d.so.7
libboost_thread-gcc44-mt-d-1_41.so => /usr/local/lib/libboost_thread-gcc44-mt-d-1_41.so
libboost_system-gcc44-mt-d-1_41.so => /usr/local/lib/libboost_system-gcc44-mt-d-1_41.so
libboost_regex-gcc44-mt-d-1_41.so => /usr/local/lib/libboost_regex-gcc44-mt-d-1_41.so
librt.so.1 => /usr/lib/hpux64/librt.so.1
libstdc++.so.6 => /opt/hp-gcc-4.4.0/lib/gcc/ia64-hp-hpux11.23/4.4.0/../../../hpux64/libstdc++.so.6
libm.so.1 => /usr/lib/hpux64/libm.so.1
libgcc_s.so.0 => /opt/hp-gcc-4.4.0/lib/gcc/ia64-hp-hpux11.23/4.4.0/../../../hpux64/libgcc_s.so.0
libunwind.so.1 => /usr/lib/hpux64/libunwind.so.1
librt.so.1 => /usr/lib/hpux64/librt.so.1
libm.so.1 => /usr/lib/hpux64/libm.so.1
libunwind.so.1 => /usr/lib/hpux64/libunwind.so.1
libdl.so.1 => /usr/lib/hpux64/libdl.so.1
libunwind.so.1 => /usr/lib/hpux64/libunwind.so.1
libc.so.1 => /usr/lib/hpux64/libc.so.1
libuca.so.1 => /usr/lib/hpux64/libuca.so.1

Глядя на трассировку стека, кажется странным, что, хотя в списке ldd используется библиотека libstdc ++ для g ++, в сообщении об использовании копии std: string ctor указано в libstd_v2, реализация которой обеспечивается aCC.

Сбой происходит в следующем коде, когда метод str () возвращает:

class JniString {
std::string m_utf8;

public:
JniString(JNIEnv* env, jstring instance) {
const char* utf8Chars = env->GetStringUTFChars(instance, 0);
if (utf8Chars == 0) {
env->ExceptionClear(); // RPF
throw std::runtime_error("GetStringUTFChars returned 0");
}
m_utf8.assign(utf8Chars);
env->ReleaseStringUTFChars(instance, utf8Chars);
}

std::string str() const {
return m_utf8;
}
};

Одновременное использование двух реализаций C ++ может быть причиной сбоя, но этого не должно происходить.

Есть идеи?

Answer 1

У нас есть проект, который использует jni на IA64, ниже скрипт скомпилирует 'libosapij.so.0'. Опции компиляции aCC могут помочь:

$ cat make.sh

export CLASSPATH=.:$CLASSPATH;
TGT="libosapij.so"
CXX="aCC +DD64 +eh -ext -AA -mt -b"

rm -f com_hp_os_OSAPI.h;
rm -f $TGT;
rm -f com/hp/os/OSAPI.class;
rm -f com/hp/os/TestApp.class;

$JAVA_HOME/bin/javac com/hp/os/OSAPI.java;
$JAVA_HOME/bin/javac com/hp/os/TestApp.java;
$JAVA_HOME/bin/javah -jni com.hp.os.OSAPI;

SRC="com_hp_os_OSAPI.cc";
INC="-I$JAVA_HOME/include -I$JAVA_HOME/include/hp-ux -I../APP/include";
MY_LIBS="../APP/lib/libosapi.a";
OS_LIBS="-L./ -lrwtool_v2 -lstd_v2 -lm";

echo "$CXX -o $TGT $SRC $INC $MY_LIBS $OS_LIBS";
$CXX -o $TGT $SRC $INC $MY_LIBS $OS_LIBS
echo "cp $TGT $TGT.0";
cp $TGT $TGT.0

echo "unit test"
echo "$JAVA_HOME/bin/java -d64 -Djava.library.path=./  com.hp.os.TestApp"
$JAVA_HOME/bin/java -d64 -Djava.library.path=./  com.hp.os.TestApp
echo "Done!"

Answer 2

Я знаю, что, вероятно, было бы неплохо спросить о HP-UX на их сайте HP-UX .

Что касается этого сбоя, вы можете попробовать обычные шаги, такие как установка последних исправлений для библиотек HP libpthread.so и libunwind.so.

Если сбой происходит в одном из потоков POSIX, может быть полезно убедиться, что ваши потоки POSIX имеют достаточно стекового пространства. Один из способов сделать это (если у вас последняя версия libpthread):

# up to 10 Mb you can set as far as I remember
# here I set arounf 2Mb for each POSIX thread
# it works if you do not set your own stack size for threads
export PTHREAD_DEFAULT_STACK_SIZE=2000000
./your_application