JNI code crash with core dump when throw is called under 64 bit

匿名 (未验证) 提交于 2019-12-03 09:14:57

问题:

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.

The problem occurred when trying to run an application under java 8 on intel SunOs.

The flag -m64 has been added to the Makefile and library was added to the LD_PRELOAD_64 and LD_LIBRARY_PATH_64 has been set correctly.

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 # 

The native code

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()); } 

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$ 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 () 

回答1:

The issue has been resolved:

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 

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



标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!