how to debug SIGSEGV in jvm GCTaskThread

Question

My application is experiencing cashes in production. The crash dump indicates a SIGSEGV has occurred in GCTaskThread

It uses JNI, so there might be some source for memory corruption, although I can't be sure.

How can I debug this problem - I though of doing -XX:OnError... but i am not sure what will help me debug this.

Also, can some of you give a concrete example on how JNI code can crash GC with SIGSEGV

EDIT:

OS:SUSE Linux Enterprise Server 10 (x86_64)

vm_info: Java HotSpot(TM) 64-Bit Server VM (11.0-b15) for linux-amd64 JRE (1.6.0_10-b33), built on Sep 26 2008 01:10:29 by "java_re" with gcc 3.2.2 (SuSE Linux)

EDIT: The issue stop occurring after we disable the hyper threading, any thoughts?

Answer 1

Errors in JNI code can occur in several ways:

The program crashes during execution of a native method (most common).
The program crashes some time after returning from the native method, often during GC (not so common).
Bad JNI code causes deadlocks shortly after returning from a native method (occasional).

If you think that you have a problem with the interaction between user-written native code and the JVM (that is, a JNI problem), you can run diagnostics that help you check the JNI transitions. to invoke these diagnostics; specify the -Xcheck:jni option when you start up the JVM.

The -Xcheck:jni option activates a set of wrapper functions around the JNI functions. The wrapper functions perform checks on the incoming parameters. These checks include:

Whether the call and the call that initialized JNI are on the same thread.
Whether the object parameters are valid objects.
Whether local or global references refer to valid objects.
Whether the type of a field matches the Get<Type>Field or Set<Type>Field call.
Whether static and nonstatic field IDs are valid.
Whether strings are valid and non-null.
Whether array elements are non-null.
The types on array elements.

Pls read the following links http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/html/jni_debug.html http://www.oracle.com/technetwork/java/javase/clopts-139448.html#gbmtq

Answer 2

Use valgrind. This sounds like a memory corruption. The output will be verbose but try to isolate the report to the JNI library if its possible.

Answer 3

Since the faulty thread seems to be GCTaskThread, did you try enabling verbose:gc and analyzing the output (preferably using a graphical tool like samurai, etc.)? Are you able to isolate a specific lib after examining the hs_err file?

Also, can you please provide more information on what causes the issue and if it is easily reproducible?