- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- libstd_v2 in stack trace of JNI code compiled with...
Operating System - HP-UX
1753664
Members
5788
Online
108798
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-25-2010 06:46 AM
03-25-2010 06:46 AM
libstd_v2 in stack trace of JNI code compiled with g++
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?
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
(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?
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-25-2010 03:55 PM
03-25-2010 03:55 PM
Re: libstd_v2 in stack trace of JNI code compiled with g++
Java is written in aC++. This means you can't use g++ for your JNIs, since you can't mix and match aC++ and g++.
>it seems odd that, although ldd list g++'s libstdc++ is being used, the std:string copy ctor being reported as used is the one in libstd_v2, the implementation provided by aC++.
It uses that one because that comes first in the binding order.
>Simultaneous usage of the two C++ implementations could likely be a reason for the crash
That's the reason.
I suppose if you are already using LD_LIBRARY_PATH, you could create an "empty" libstd_v2.so.1 and then see if your JNI works?
touch empty.c
cc -b -o libstd_v2.so.1 empty.c
>it seems odd that, although ldd list g++'s libstdc++ is being used, the std:string copy ctor being reported as used is the one in libstd_v2, the implementation provided by aC++.
It uses that one because that comes first in the binding order.
>Simultaneous usage of the two C++ implementations could likely be a reason for the crash
That's the reason.
I suppose if you are already using LD_LIBRARY_PATH, you could create an "empty" libstd_v2.so.1 and then see if your JNI works?
touch empty.c
cc -b -o libstd_v2.so.1 empty.c
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP