JVM crash at CompilerThread

My java application is crashing almost consistently when trying to compile a specific method (it's always the same method), with SIGSEGV:

 A fatal error has been dete开发者_运维百科cted by the Java Runtime Environment:

  SIGSEGV (0xb) at pc=0x00002aaaab6642a5, pid=8348, tid=1087596864

 JRE version: 6.0_16-b01
 Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
 Problematic frame:
 V  [libjvm.so+0x5332a5]

 An error report file with more information is saved as:
 hs_err_pid8348.log

 If you would like to submit a bug report, please visit:
   http://java.sun.com/webapps/bugreport/crash.jsp

The crash log (interesting parts...):

 A fatal error has been detected by the Java Runtime Environment:

  SIGSEGV (0xb) at pc=0x00002aaaab6642a5, pid=8348, tid=1087596864

 JRE version: 6.0_16-b01
 Java VM: Java HotSpot(TM) 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
 Problematic frame:
 V  [libjvm.so+0x5332a5]

 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 (0x00002aab1f7ac800):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=8694, stack(0x0000000040c36000,0x00000000
40d37000)]

I tried to create a core dump and connect to it, but I couldn't find the CompilerThread there (maybe it's been killed be

---

Post the entire page (w/ the extra info on the libraries) with the stack and more if can get. You can't see ANY thread if you see the core dump.

If the problem includes zlib (ZipEntry), you are partyly out of luck... It's a very annoying BUG in zlip with very very bold and it occurs if the zip (jar) is changed after being open. I still wonder why Sun/Oracle uses a native library for zip processing since doing it in purely java is more stable and ... 2 times faster (performance wise).

---

Manually optimize the method involved.

Current thread (0x00002aab1f7ac800): JavaThread "CompilerThread0" daemon [_thread_in_native, id=8694, stack(0x0000000040c36000,0x00000000 40d37000)]

Just below this line, you should see the specific method that the hotspot engine was trying to optimize. You have likely hit some code in hotspot that has some problems. It will be very hard to determine exactly what code was hit and why.

I've had this problem occur, and I solved it. The method involved was written in a very non-optimized fashion. Unnecessary data structures were created, extra loops were added, and also extra variables created and used only once. I iteratively optimized more and more of this method until it finally didn't throw the exception after the final iteration which was pretty low-level almost nit-picky optimizations.

I believe that in the end, there was a bug in some sort of byte-code optimization routine that was being triggered in the hotspot engine. There's almost no way of knowing exactly what was happening. But I think that by optimizing the code manually, I optimized the byte-code in such a way that the hotspot engine no longer ran the buggy routine.

I know that this is nothing definite, but I hope that my story can help you and future visitors. Best of luck!

---

JRE version 6.0_16 is rather old. I recommend upgrading to the current JRE, there's a very good chance this crash will have been fixed.

---

If this is an option, you can exclude the method that is causing the crash from runtime by adding this parameter to java executable call -XX:CompileCommand=exclude,com/path/to/class/in/Jar$InnerClassIfAny.methodName

The name of the class and method that cause the crash can be found in the crash report (hs_err_pidxxxx.log) right above the

--------------- P R O C E S S ---------------

mark.

Note: on a Unix environment, the inner class (if any) should be escaped like this \$ instead of $.