在64位以下調用throw時，JNI代碼崩潰並發生核心轉儲

Question

我正在使用java + c ++（使用JNI）工作，我必須加載自己的本機庫，但是調用throw時應用程序由於核心轉儲而失敗，盡管該代碼被異常處理程序包圍（請參見下面的代碼）。 這是在linux 64位，sparc 64位和i386 32位上正常工作的相同代碼。

嘗試在intel SunO上的Java 8下運行應用程序時出現問題。

標志-m64已添加到Makefile，庫已添加到LD_PRELOAD_64，並且LD_LIBRARY_PATH_64已正確設置。

Java啟動成功加載庫並運行本機代碼（Java_com_jnetx_usw_chp_CHPMain_start）並在拋出時崩潰：

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）？

-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自由軟件基金會，公司。 請參閱復制條件的來源。 沒有保修； 甚至不是出於適銷性或針對特定目的的適用性。

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

Answer 1

該問題已解決：

這兩個之間存在一個已知問題，即ABI略有不匹配（libgcc_s.so：_Unwind_RaiseException和Solaris libc.so：_Unwind_RaiseException）。 將符號綁定到GCC運行時首先會導致它在Solaris運行時之前被加載，並且一切正常。 但是，僅將其顯式添加到我們的共享庫鏈接行中無濟於事。

所以我的簡單解決方法對我有幫助：

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