Jvm Crash Due to Sigsegv

Best way on how to solve/debug JVM crash (SIGSEGV)

The crash report tells the error has happened in JIT compiler thread:

Current thread (0x00007f89e481c800):  JavaThread "C2 CompilerThread1"

Take the following steps do diagnose compiler problems:

1. Try the most recent JVM build available in JDK 9 EA: https://jdk9.java.net/download/

   If the problem disappears, you can either stay with this version or try to locate the exact commit that solves the issue and then backport it to JDK 8. How to backport fixes and how to build HotSpot yourself - it's a separate topic, but I can tell if you're interested.

2. If the problem persists, try to find a problematic method and exclude it from compilation.

   Current CompileTask: C2: 114667 5303 4 com.sosse.time.timeseries.gson.TypeConverterHelper::deserialize (157 bytes)
   

   Looks like in your case it fails compiling TypeConverterHelper.deserialize(). Add the following JVM option to exclude this particular method:

   -XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.TypeConverterHelper::deserialize
   

3. If it does not help, try to exclude more methods by providing multiple -XX:CompileCommand. To find candidates to exclude use -XX:+PrintCompilation and look at the bottom of the printed list. You can also exclude the whole classes and packages from compilation, e.g.

   -XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.*::*
   

4. Try to disable certain compiler optimizations one by one. Some options to try are:

   -XX:-DoEscapeAnalysis
   -XX:LoopUnrollLimit=0
   -XX:-PartialPeelLoop
   -XX:-UseLoopPredicate
   -XX:-LoopUnswitching
   -XX:-ReassociateInvariants
   -XX:MaxInlineLevel=1
   -XX:-IncrementalInline
   -XX:-RangeCheckElimination
   -XX:-EliminateAllocations
   -XX:-UseTypeProfile
   -XX:AliasLevel=0
   

5. Whether the problematic method/optimization is found or not, run JVM again with

   -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation
   

   This will create hotspot_pid1234.log file in the current directory with detailed compilation log.

6. Submit the bug report at bugreport.java.com. Select

   Product/Category: HotSpot Virtual Machine (errors)
   Subcategory:      J2SE Server Compiler
   

   Make sure to include full hs_err_pid.log and hotspot_pid.log from step 5. It would be very helpful if you could provide a reduced self-contained example that demonstrates the problem.

   For a faster reaction you may also post a message to hotspot-compiler-dev mailing list.

JVM SIGSEGV crash in native without any named library

You only posted one full log so it's not really possible to spot a pattern here, but the C frame is in a non-executable memory region and outside the code space. The VM events also show a flurry of re/deoptimizations and a bias revocation. So my guess is that might be a miscompilation.

Things you can try:

1. update your JVM. 8.0_60-b27 is not the latest patch level.
2. try -XX:-UseBiasedLocking -XX:-TieredCompilation
3. try -XX:-UseBiasedLocking -XX:TieredStopAtLevel=1

If updating the vm does not fix it but one of the options does then it's probably a VM bug and you should file with your linux distribution or oracle.

Can a SIGSEGV in Java not crash the JVM?

Can a SIGSEGV in Java not crash the JVM?

Sure, if a SIGSEGV occurs while executing Java code (not native code) it is most likely due to dereferencing a Java null. That can be trapped and turned into a NullPointerException and "thrown". An application can recover from this; i.e. by "catching" the exception.

I think that a SIGSEGV could also be triggered by a Java stack overflow causing the Java code to read or write an address in a stack's "red zone" memory segment.

Anyhow, there are definitely scenarios where the JVM's SIGSEGV signal handler may turn the SIGSEGV event into a Java exception. You will only get a JVM hard crash if that can't happen; e.g. if the thread that triggered the SIGSEGV was executing code in a native library when the event happened.

how to debug SIGSEGV in jvm GCTaskThread

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

---

Related Topics