在64位以下调用throw时，JNI代码崩溃并发生核心转储 [英] JNI code crash with core dump when throw is called under 64 bit
问题描述
我正在使用Java + c ++（使用JNI），并且我必须加载自己的本机库，但是当调用被称为throw时，应用程序会因核心转储而失败，尽管该代码被异常处理程序包围（请参见下面的代码）。相同的代码在linux 64位，sparc 64位和i386 32位上都可以正常工作。
I'm working with java + c++ ( using JNI ) and i must load own native libraries but application failed with core dump when throw is called lthough the code is surrounded by an exception handler (see code below). It's the same code working without problem on linux 64bit, sparc 64bit and i386 32bit.
尝试在intel SunOs上的Java 8下运行应用程序时出现问题。
The problem occurred when trying to run an application under java 8 on intel SunOs.
标志-m64
Java启动成功加载了库并运行了本机代码（Java_com_jnetx_usw_chp_CHPMain_start）。并在抛出时崩溃：
The java starting, successfully load library and run the native code (Java_com_jnetx_usw_chp_CHPMain_start) and crash on the throw:
INF:17:59:33.20:CHP main(27): CHPMain.run: ok load chp library. Start it...
NOT:17:59:33.22:CHP main(27): CHPMain.run: -> chp.start
Wed Nov 8 17:59:34 CHP::startTest : cycle = 1
Wed Nov 8 17:59:35 CHP::startTest : cycle = 2
Wed Nov 8 17:59:35 Try cause Exception...
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000000012ab5, pid=10081, tid=0x0000000000000026
#
# JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode solaris-amd64 compressed oops)
# Problematic frame:
# C 0x0000000000012ab5
#
# Core dump written. Default location: /home/kcc_64/x2001/bin/core or core.10081
#
# An error report file with more information is saved as:
# /home/kcc_64/x2001/bin/hs_err_pid10081.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
本机代码
JNIEXPORT void JNICALL Java_com_jnetx_usw_chp_CHPMain_start
(JNIEnv *env, jobject jobj, jint trc_level,jobjectArray j_argv,jobject chp_main,jobject chp_smp)
{
chp = new CHP();
chp->startTest();
}
void CHP::startTest() {
int t = 1;
while (true) {
try {
poll(NULL, 0, 1000);
fprintf(stderr, "%s CHP::startTest : cycle = %d\n", getTime(), t++);
if ( 3 == t ) {
fprintf(stderr, "%s : Try generate Exception... \n", getTime());
throw 20;
}
}
catch (const int & e) {
fprintf(stderr, "%s : Catch, e = %d\n", getTime(), e);
break;
}
catch (...) {
fprintf(stderr, "%s : Catch unknown exception...\n", getTime());
break;
}
}
fprintf(stderr, "%s : CHP::startTest : End thread, exit\n", getTime());
}
为什么catch块被忽略，我们立即转到系统信号处理程序以核心转储结束（请参见下面的pstack）？
Why the catch block is ignored and immediately we go to the system signal handler which ends with core dump (see pstack below)?
-bash-3.00 $ uname -a
SunOS x2001 5.10 Generic_142910-17 i86pc i386 i86pc
-bash-3.00 $ pstack core
-bash-3.00$ uname -a SunOS x2001 5.10 Generic_142910-17 i86pc i386 i86pc -bash-3.00$ pstack core
-bash-3.00 $ gcc --version
gcc（GCC）4.4.2
版权所有（C） 2009 Free Software Foundation，Inc.
这是免费软件；请参阅复制条件的来源。没有
保修；
-bash-3.00$ gcc --version gcc (GCC) 4.4.2 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pflags core
/38: flags = DETACH
sigmask = 0xfffffeff,0x0000ffff cursig = SIGABRT
pstack core
fffffd7fff291aea _lwp_kill () + a
fffffd7fff236c39 raise () + 19
fffffd7fff215bb0 abort () + 90
...
fffffd7ffe9d0343 JVM_handle_solaris_signal () + 8d7
fffffd7ffe9c8617 signalHandler () + 2f
fffffd7fff28c2e6 __sighndlr () + 6
fffffd7fff280bc2 call_user_handler () + 252
fffffd7fff280dee sigacthandler (b, fffffd7f7e2f5208, fffffd7f7e2f4ea0) + ee
--- called from signal handler with signal 11 (SIGSEGV) ---
0000000000013dd5 ???????? () + 28000d930d5
fffffd7fff2904d9 _SUNW_Unwind_RaiseException () + 46
fffffd7f7dea2c53 __cxa_throw () + 9b !!!!!!!!!
fffffd7f7f213310 _ZN3CHP9startTestEv () + 190
fffffd7fee215a14 * com/jnetx/usw/chp/CHPMain.start(I[Ljava/lang/String;Lcom/jnetx/usw/chp/CHPMain;Lcom/jnetx/usw/chp/CHPSmp;)V+0
fffffd7fee2083b6 * com/jnetx/usw/chp/CHPMain.run([Ljava/lang/String;Lcom/jnetx/usw/chp/CHPUpdateListener;)V+563 (line 377)
fffffd7fee2083b6 * com/jnetx/usw/chp/CHPProvider$1.run()V+20 (line 374)
fffffd7fee2007a7 * com/jnetx/usw/chp/CHPProvider$1.run()V+17760
fffffd7ffe4c10ff __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ () + 8d7
fffffd7ffe4bcd3c __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_pnGSymbol_5pnRJavaCallArguments_pnGThread__v_ () + 424
fffffd7ffe4bd124 __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_pnGSymbol_6pnGThread__v_ () + 60
fffffd7ffe64030c __1cMthread_entry6FpnKJavaThread_pnGThread__v_ () + b8
fffffd7ffebd9679 __1cKJavaThreadDrun6M_v_ () + 5e1
fffffd7ffe9bdc85 java_start () + 175
fffffd7fff28bfbb _thr_setup () + 5b
fffffd7fff28c1e0 _lwp_start ()
推荐答案
问题已解决：
这两个之间存在一个已知的问题，其ABI稍有不匹配（libgcc_s .so：_Unwind_RaiseException和Solaris libc.so：_Unwind_RaiseException）。将符号绑定到GCC运行时首先会导致它在Solaris运行时之前被加载，并且一切正常。但是，仅将其显式添加到共享库链接行中并没有任何帮助。
There is a known issue with a slight mismatch in the ABI between these two (libgcc_s.so: _Unwind_RaiseException and Solaris libc.so: _Unwind_RaiseException). Binding symbols to the GCC runtime first causes it to be loaded before the Solaris runtime, and everything works out well. But, simply adding this explicitly to our shared library link line did not help anything.
所以我的简单解决方法对我有帮助：
so my simple workaround helped me:
LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so
主要原因是我使用的是gcc版本，但使用的是4.4，但已在4.9版中进行了修复-
在64位Solaris 10 + / x86上混合libc和libgcc_s解卷器会破坏EH
https://gcc.gnu.org/bugzilla/show_bug.cgi ？id = 59788
The main reason has been in the version of gcc, i used 4.4, but fix has been made in 4.9 - Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788
这篇关于在64位以下调用throw时，JNI代码崩溃并发生核心转储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
