HP-UX: libstd_v2 in stack trace of JNI code compiled with g++
- by Miguel Rentes
Hello,
uname -mr: B.11.23 ia64
g++ --version: g++ (GCC) 4.4.0
java -version:
Java(TM) SE Runtime Environment (build 1.6.0.06-jinteg_20_jan_2010_05_50-b00)
Java HotSpot(TM) Server VM (build 14.3-b01-jre1.6.0.06-rc1, mixed mode)
I'm trying to run a Java application that uses JNI. It is crashing inside the JNI code with the following (abbreviated) stack trace:
(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]
This JNI code and dependencies are being compiled using g++, are multithreaded and 64 bit (-pthread -mlp64 -shared -fPIC). The LD_LIBRARY_PATH environment variable is set the dependencies location, and running ldd on the JNI shared libraries finds them all:
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
Looking at the stack trace, it seams odd that, although ldd list g++'s libstdc++ is being used, the std:string copy c'tor being reported as used is the one in libstd_v2, the implementation provided by aCC.
The crash happens in the following code, when method str() returns:
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;
}
};
Simultaneous usage of the two C++ implementations could likely be a reason for the crash, but that should not be happening.
Any ideas?
