JVM core dump - JNI code

Question

I am using JNI in my Java application , 12 hours after running my test case get a JVM crash -
1) These are the parameters with which i invoke my Java program
java -d64 -Xcheck:jni -Xmx2560M -Xms2560M -Xss256k RunQueries
2) The Heap output at the time of the core shows "from space" as 100% used , does this signify anything?
Heap at VM Abort:
Heap
def new generation total 848128K, used 672342K [0xfffffffe93c00000, 0xfffffffec9150000, 0xfffffffec9150000)
eden space 822464K, 78% used [0xfffffffe93c00000, 0xfffffffebb385b90, 0xfffffffec5f30000)
from space 25664K, 100% used [0xfffffffec7840000, 0xfffffffec9150000, 0xfffffffec9150000)
to space 25664K, 0% used [0xfffffffec5f30000, 0xfffffffec5f30000, 0xfffffffec7840000)
tenured generation total 1747648K, used 1350866K [0xfffffffec9150000, 0xffffffff33c00000, 0xffffffff33c00000)
the space 1747648K, 77% used [0xfffffffec9150000, 0xffffffff1b884830, 0xffffffff1b884a00, 0xffffffff33c00000)
compacting perm gen total 16384K, used 13550K [0xffffffff33c00000, 0xffffffff34c00000, 0xffffffff37c00000)
the space 16384K, 82% used [0xffffffff33c00000, 0xffffffff3493b860, 0xffffffff3493ba00, 0xffffffff34c00000)
Local Time = Mon Feb 12 21:49:40 2007
Elapsed Time = 61687
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.2_07-b05 mixed mode)
3) A dbx on the Java core shows the location in the JNI code where the core dump occured.
dbx `which java` core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.3' in your .dbxrc
Reading java
dbx: internal warning: writable memory segment 0x7cb00000[16384] of size 0 in core
core file header read successfully
Reading ld.so.1
Reading libthread.so.1
Reading libdl.so.1
Reading libc.so.1
Reading libc_psr.so.1
Reading libjvm.so
Reading libCrun.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.1
WARNING!!
A loadobject was found with an unexpected checksum value.
See `help core mismatch' for details, and run `proc -map'
to see what checksum values were expected and found.
dbx: warning: Some symbolic information might be incorrect.
t@1 (l@1) terminated by signal ABRT (Abort)
0xffffffff7eea822c: lwpkill+0x0008: bcc,a,pt %icc,_lwp_kill+0x18 ! 0xffffffff7eea823c
Current function is Java_getLoid (optimized)
7239 e = cod_to_long (*(o_object*) data, &loid_as_long);
(dbx) where
current thread: t@1
[1] lwpkill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7eea822c
[2] raise(0x6, 0x0, 0xffffffff7fffad30, 0x7fbffeff00003ff6, 0x0, 0x2), at 0xffffffff7ee58a8c
[3] abort(0x0, 0xffffffff7fffae10, 0x0, 0xfffffffffffffff8, 0x0, 0xffffffff7fffae39), at 0xffffffff7ee3e3b8
[4] os::abort(0x1, 0xffffffff7e9d295c, 0xffffffff7fffaf10, 0xffffffff7e9d24a9, 0x4b007c, 0xffffffff7eb78878), at 0xffffffff7e90951c
[5] os::handle_unexpected_exception(0x10011e600, 0xa, 0xfffffffe90345704, 0xffffffff7fffbeb0, 0xffffffff7e69c6f8, 0x0), at 0xffffffff7e907e08
[6] JVM_handle_solaris_signal(0xffffffff7fffbeb0, 0xffffffff7e9d443e, 0xffffffff7fffbbd0, 0x1, 0x0, 0x1), at 0xffffffff7e69c800
[7] __sighndlr(0xa, 0xffffffff7fffbeb0, 0xffffffff7fffbbd0, 0xffffffff7e69cb9c, 0x0, 0x0), at 0xffffffff7f2188d8
---- called from signal handler with signal 10 (SIGBUS) ------
=>[8] Java_getLoid(vjEnv = ???, cls = ???, handle = ???, attr = ???) (optimized), at 0xfffffffe90345704 (line ~7239) in "j.c"
I have added checks for this function call to ensure that no invalid pointer is being sent to it which could cause a segmentation violation.
Please could someone give me some pointers on how to solve this problem, the error occurs at this point only 12 hours after running the test case..

Answer 1

First step is to add the option -Xcheck:jni to your java command line. It will flag common JNI errors.
If that doesn't identify the problem, then compile your jni code with debugging symbols (-g) and add the following option to the java command line when you run your test: -XX:+ShowMessageBoxOnError. When you hit the problem again, the VM will keep the process alive instead of calling abort(). Then you can use dbx to attach to the live process and should be able to get a better idea of what went wrong.