java - JVM 在 CompilerThread 崩溃

Question

当尝试使用 SIGSEGV 编译特定方法(始终是相同的方法)时，我的 java 应用程序几乎一直崩溃:

 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]

 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

崩溃日志(有趣的部分...):

 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)]

我尝试创建一个核心转储并连接到它，但我在那里找不到 CompilerThread(也许它已被杀死

Answer 1

发布整个页面(带有有关库的额外信息)以及堆栈以及更多内容(如果可以获得)。如果您看到核心转储，则看不到任何线程。

如果问题包括 zlib (ZipEntry)，那么你就运气不好了......这是 zlip 中非常非常粗体的一个非常烦人的 BUG，如果 zip (jar) 在打开后发生更改，就会发生这种情况。我仍然想知道为什么 Sun/Oracle 使用 native 库进行 zip 处理，因为用纯 java 进行处理更稳定并且......速度快 2 倍(性能方面)。