AttachCurrentThread SEGV linux Itanium 64 Java 6

Question

I have a Java application which is core dumping. This application has a JNI component. The JNI component tries to attach a native thread to VM to do a call back to Java method. SEGC occurs while doing AttachCurrentThread. Here is a code snippet.
JNIEnv *env;
JavaVM *jvm_local;
jsize nVMs;
/* Get the JNI Env from the JVM */
/* JNI_GetCreatedJavaVMs(JavaVM **vmBuf, jsize bufLen, jsize nVMs); /
if(JNI_GetCreatedJavaVMs(&jvm_local, 1, &nVMs) != JNI_OK) return -1;
(*jvm_local)->AttachCurrentThread(jvm_local, (void **)&env, NULL);
Java dump
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x2000000000b30560, pid=7537, tid=2305843011812471424
# JRE version: 6.0_17
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode linux-ia64 )
# Problematic frame:
# V [libjvm.so+0x7dc560]
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
--------------- T H R E A D ---------------
Current thread (0x60000000002bf000): JavaThread "<no-name - thread is attaching>" [_thread_in_vm, id=7737, stack(0x200000009ae50000,0x200000009ae64000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), si_addr=0x0000000000000030
I looked at the core generated. See below:
(gdb) where
#0 0xa000000000010640 in __kernel_syscall_via_break ()
#1 0x20000000001274b0 in raise () from /lib/tls/libc.so.6.1
#2 0x2000000000129db0 in abort () from /lib/tls/libc.so.6.1
#3 0x200000000115dff0 in os::abort ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#4 0x200000000143c540 in VMError::report_and_die ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#5 0x200000000116a720 in JVM_handle_linux_signal ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#6 0x200000000115adb0 in signalHandler ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#7 <signal handler called>
#8 0x2000000000b30560 in frame::compiled_sender_sp ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#9 0x2000000000b334b0 in frame::sender ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#10 0x2000000000cfc230 in java_lang_Throwable::fill_in_stack_trace ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#11 0x2000000000cfc850 in java_lang_Throwable::fill_in_stack_trace ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#12 0x2000000000b17900 in Exceptions::throw_stack_overflow_exception ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#13 0x2000000000ce6f00 in JavaCalls::call_helper ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#14 0x2000000001157d40 in os::os_exception_wrapper ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#15 0x2000000000ce48d0 in JavaCalls::call ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#16 0x2000000000ce4ca0 in JavaCalls::call_special ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#17 0x2000000000ce5130 in JavaCalls::call_special ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#18 0x200000000138aee0 in JavaThread::allocate_threadObj ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#19 0x2000000000d00780 in attach_current_thread ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#20 0x2000000000d00c80 in jni_AttachCurrentThread ()
from /strnas02/local/java/jdk1.6.0_17/jre/lib/ia64/server/libjvm.so
#21 0x200000008b33bd30 in genericACFConnectionCallback (
hdbc=0x60000000003b6bd0, param=0x0, foType=0, foEvent=1) at JdbcOdbc.c:4627
#22 0x200000008b3ada40 in FailoverCallbackThread (a=0x600000000021cf60)
at /ade/mardhana_him_gcia64linux1/timesten/VisiChannel/oc/src/vocctx.cpp:666
#23 0x200000000006d7f0 in start_thread () from /lib/tls/libpthread.so.0
#24 0x200000000026f9f0 in __clone2 () from /lib/tls/libc.so.6.1
I see Exceptions::throw_stack_overflow_exception (). Is this a "reliable" indication that there was stack overflow? Here is the VM info:
OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
uname:Linux 2.6.9-34.0.1.0.11.EL #1 SMP Mon Dec 4 14:42:32 PST 2006 ia64
libc:glibc 2.3.4 NPTL 2.3.4
rlimit: STACK 16000k, CORE infinity, NPROC 16315, NOFILE 1024, AS infinity
load average:1.37 1.24 1.23
CPU:total 4 Itanium 2 Madison 9M, family 31 model 2 revision 1, lb
Memory: 16k page, physical 8244064k(688096k free), swap 2097120k(2095872k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (14.3-b01) for linux-ia64 JRE (1.6.0_17-b0405), built on Oct 14 2009 21:17:59 by "lab_ipfjbld" with gcc 4.2.0
I will appreciate any pointers.
With regards,
mp

Answer 1

jschell wrote:
# SIGSEGV The most likely cause of that in an app with JNI code is a C/C++ pointer bug. That is followed by a misuse of an API (which is going to end up resolving to a pointer error too.)
Pointer bugs do not necessarily produce immediate errors. They can cause the app to fail in unexpected ways almost anywhere after the point where the bug occurred. A common indicator of this is if the code changes or the execution through the code changes then a different bug (location) occurs.I suspected that "stack overflow" is not a good indicator (especially based on some of your older posts). I do not understand what you mean by -- That is followed by a misuse of an API (which is going to end up resolving to a pointer error too.). I am using the VM pointer and am attaching a native thread to it to call back into Java layer. Can you please elaborate on the misuse?
Edited by: coffeeguy on Apr 8, 2010 1:11 PM
Edited by: coffeeguy on Apr 8, 2010 1:27 PM