java - Desplome de código JNI con volcado de núcleo cuando se llama throw bajo 64 bit

c++ 64bit

Question

Estoy trabajando con java + c ++ (usando JNI) y debo cargar mis propias bibliotecas nativas, pero la aplicación falló con el volcado del núcleo cuando se llama throw aunque el código está rodeado por un manejador de excepciones (ver código a continuación). Es el mismo código que funciona sin problemas en Linux 64bit, sparc 64bit e i386 32bit.

El problema ocurrió al intentar ejecutar una aplicación bajo java 8 en intel SunOs.

El indicador -m64 se ha agregado al Makefile y la biblioteca se agregó a LD_PRELOAD_64 y LD_LIBRARY_PATH_64 se ha configurado correctamente.

El java starting, carga con éxito la biblioteca y ejecuta el código nativo (Java_com_jnetx_usw_chp_CHPMain_start) y se bloquea en el lanzamiento:

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
#

El código nativo

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

¿Por qué se ignora el bloque catch e inmediatamente vamos al manejador de señal del sistema que termina con el volcado del núcleo (ver pstack a continuación)?

-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. Esto es software libre; ver la fuente de las condiciones de copia. NO hay garantía; ni siquiera para COMERCIABILIDAD o IDONEIDAD PARA UN PROPÓSITO PARTICULAR.

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

El problema ha sido resuelto:

Existe un problema conocido con una ligera falta de coincidencia en el ABI entre estos dos (libgcc_s.so: _Unwind_RaiseException y Solaris libc.so: _Unwind_RaiseException). Al vincular símbolos al tiempo de ejecución de GCC, primero se carga antes del tiempo de ejecución de Solaris, y todo funciona bien. Pero, simplemente agregar esto explícitamente a nuestra línea de enlace de biblioteca compartida no ayudó en nada.

entonces mi solución simple me ayudó:

LD_PRELOAD=/usr/sfw/lib/amd64/libgcc_s.so

La razón principal ha estado en la versión de gcc, utilicé 4.4, pero se corrigió en 4.9 - Mezcla libg y libgcc_s desbobinadores en Solaris 10 + / x86 de 64 bits rompe EH https://gcc.gnu.org/bugzilla /show_bug.cgi?id=59788