Crashes due to native JNI Exception with 64 bit built binary
 

Hi,

I am getting a crash when a native exception through JNI is propagated to Java. The source code is really simple and it just throws a native exception. I think the process crashes when it tries to unwind the stack after an exception is thrown. You can see the error below. One more thing, it only happens when the native library is compiled on 64 bit arch, and it does work successfully on 32 bit arch. I am using gcc compiler and stats are mentioned below as well. Let me know if you need more information. One more thing, this code works perfectly well in Linux systems and i could see one compiler option "--disable-libunwind-exceptions" on Linux. Does this option really play any role for these kind of exceptions ? Should we put this option whiling building gcc compiler on Solaris box ?

uname: SunOS
uname -m: i86pc

compiler info
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/export/home/gcc4/bin/../libexec/gcc/i386-pc-solaris2.10/4.6.3/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.6.3/configure --prefix=/usr/local/gcc4 --enable-__cxa_atexit
Thread model: posix
gcc version 4.6.3 (GCC)


From Crash Report:
Stack: [0xfffffd7fffbff000,0xfffffd7fffe00000), sp=0xfffffd7fffdfe4d8, free space=2045k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x00000000000129f5
C [libc.so.1+0xe08b9] _Unwind_RaiseException+0x46
C [libstdc++.so.6.0.16+0xf4a79] __cxa_throw+0x59
C [libtestjni.so+0x1d92] Java_testJava_TEST+0xca
j testJava.TEST()I+0
j testJava.main([Ljava/lang/String;)V+14
v ~StubRoutines::call_stub
V [libjvm.so+0x401398]
V [libjvm.so+0x401618]
V [libjvm.so+0x4018dd]
V [libjvm.so+0x4e6414]
V [libjvm.so+0x4ef694]
C [java+0x3169] main+0x649
C [java+0x29cc] _PROCEDURE_LINKAGE_TABLE_+0x3e4

library dependencies :
SERVER:/$HOME/simpleJNITest$ldd libtestjni.so
libstdc++.so.6 => /usr/local/gcc4/lib/amd64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/local/gcc4/lib/amd64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1

Hi,

I got the same problem on the same architecture with the same environment (only gcc version 4.4).
Did you find a solution to this problem? Could you describe solution?