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

[sccp]

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.

-bash-3.00$ uname -a SunOS x2001 5.10 Generic_142910-17 i86pc i386 i86pc
-bash-3.00$ gcc --version gcc (GCC) 4.4.2 Copyright (C) 2009 Free Software Foundation, Inc. This is free software;

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 __cxa_throw signal handler which ends with core dump (see pstack below)?

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

How my library libchp.so has been linked:

g++ -g -O2  -m64 -DSOLARIS -DSUNI386 -m64  -D_REENTRANT -fPIC -DTSD   -Wall -Wextra -std=c++0x  -shared -o libchp.so ../tmp/memtest.o   -L../tmp -lpthread -lrt -lsocket -lposix4 -lumem -ldemangle -lrt

-bash-3.00$ ldd libchp.so
     libstdc++.so.6 =>        /usr/local/gcc4/lib/amd64/libstdc++.so.6
     libgcc_s.so.1 =>         /usr/local/gcc4/lib/amd64/libgcc_s.so.1

The loaded librarys by java ( from /proc/$JAVA_PID/path )

lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 nfs.311.1559.269661 -> /home/kcc_64/x2001/lib/native/sunos/i386/libchp.so
...
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.233011 -> /opt/omni/library/libgcc_s.so.1
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.233028 -> /opt/omni/library/libstdc++.so.6
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.262550 -> /usr/jdk1.8.0_121/jre/lib/amd64/server/libjvm.so
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.3355 -> /usr/lib/amd64/libCrun.so.1
...
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.9059 -> /lib/amd64/libmd.so.1
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.9061 -> /lib/amd64/libmp.so.2
lrwxrwxrwx   1 vb rnd1  0 Nov  9 11:03 ufs.30.0.9062 -> /lib/amd64/libnsl.so.1

[Peter87]

Why is the output "Try cause Exception" when the program prints "Try generate Exception"?

[sccp]

The first version of the program printed "cause", now it prints "generated". This is only the notification to the log before the throw is called.

[sccp]

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