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

Question

I\'m really lost and I don\'t know how to face and solve my problem. I have a piece of simple Java Code, which leads to a JVM crash:

#
# A fatal error has been d         


        

Answer 1

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.

Answer 2

I think you should spend some time in analyzing the core.

Segmentation fault

There are several possible reasons for this. There could be a bug in the JVM itself, or in a package (some of these are written in C or C++). It could also be due to a misconfiguration where incompatible components are used together.

From experience, a JVM bug is the least likely of these. Although @Stephen thinks that is the likely case here.

If you capture the stack trace at the point of the crash, this might give you some clues as to where exactly the crash is occurring.

Firstly, I see that you need to confgure ulimit -c unlimited so that you can store the core file to disk.

Analyze Core file
Once you do that, you should analyze the core using the following method.

To convert the file use the commandline tool jmap.

jmap -dump:format=b,file=dump.hprof /usr/bin/java core_file

where:

dump.hprof is the name of the hprof file you wish to create

/usr/bin/java is the path to the version of the java binary that generated the core dump

Answer 3

It looks like JDK bug JDK-6675699. According to the bug report, the fix for that bug has been backported to 8u74, 8u81 and 8u82.

Note that (as of right now) the end-user focused Java Download Site offers 8u73 as the latest version. You can get 8u74 from the Java Developer Download Site.

---

If updating to 8u74 doesn't solve the problem, then you should submit this to Oracle as a bug report. The likely diagnosis is that you are running code that is causing the JIT code compiler to crash when it attempt to compile / optimize it. That's what PhaseIdealLoop::idom_no_update is indicating.

JDK-6675699 is for a specific JIT compiler bug. There could well be other JIT compiler bugs that have not been diagnosed. If you submit a new bug report, it could help the maintainers to track down those bugs. However, a bug report will only be useful to them if you can provide enough information to allow them to reproduce your bug.

(Of course, it is also possible that the root cause is something completely different; e.g. something in your code 3rd party code that is corrupting JVM data structures that is causing the compiler to crash. But it would a huge coincidence for the corruptions to repeatably break the compiler ... and only the compiler.)

---

UPDATE - According to these Release Notes, the version you actually need is Java SE 8u74-b32.