JVM 在 CompilerThread 崩溃答案

【问题标题】：JVM crash at CompilerThreadJVM 在 CompilerThread 崩溃
【发布时间】：2011-01-16 13:22:57
【问题描述】：

在尝试使用 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（可能它已经被杀死了

【问题讨论】：

标签： java crash jvm jvm-hotspot

【解决方案1】：

使用堆栈发布整个页面（带有库上的额外信息），如果可以获得更多信息。如果看到核心转储，则看不到任何线程。

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

【讨论】：

@bestsss ZipEntry - libzip.so 是什么意思？
是的（我的意思是为了取悦字符长度）
@bestsss：你有描述这个问题的链接吗？
@ekeren：我有故障转储，但行为完全可重现，但 sun 认为：“11 关闭，不可重现，错误”bugs.sun.com/bugdatabase/view_bug.do?bug_id=6366468
@bestsss：他们使用本机 zlib 也特别令人难过，因为它也已经成为至少一个安全问题的根本原因（缓冲区溢出 IIRC），如果他们使用的是 Java 编写的，这将是不可能的......但也许这里有一些 Catch-22，不知道，还没有真正研究过。

【解决方案2】：

手动优化所涉及的方法。

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

就在这一行下方，您应该看到热点引擎试图优化的具体方法。您可能在热点中遇到了一些有问题的代码。很难确定究竟是什么代码被击中以及为什么被击中。

我遇到过这个问题，我解决了。所涉及的方法是以非常未优化的方式编写的。创建了不必要的数据结构，添加了额外的循环，并且还创建了额外的变量并且只使用了一次。我对这种方法进行了越来越多的迭代优化，直到最后一次迭代后它终于没有抛出异常，这是相当低级的几乎挑剔的优化。

我相信最后，在热点引擎中触发的某种字节码优化例程中存在错误。几乎没有办法确切地知道发生了什么。但我认为通过手动优化代码，我优化了字节码，使得热点引擎不再运行错误的例程。

我知道这并不确定，但我希望我的故事可以帮助您和未来的访客。祝你好运！

【讨论】：

您是如何使用 JIT 手动优化方法的？你能告诉我吗。我也面临同样的问题。
我没有使用 JIT。就我而言，下一行中提到的方法是我的库中正在编译的方法。我通过删除不必要的代码和循环来优化该方法。如果该方法看起来已经优化，我会尝试以不同的方式分解事物 - 调整算法，使步骤略有不同。

【解决方案3】：

JRE 版本 6.0_16 相当旧。我建议升级到当前的 JRE，这个崩溃很有可能会得到修复。

【讨论】：

这是我环境中的最新版本...目前无法升级。
@duduamar：那么我担心你会遇到这个问题。你不能调试这个，除非你想进入 JVM 的二进制内部（你真的不想）。升级 JVM 是解决此问题的唯一方法。
@skafmman：你知道 6.0_16 中的一个开放错误可以解释这一点吗？
@ekeren：不具体，不。然而，这是我唯一可以建议的，而且它通常很有效。

【解决方案4】：

如果这是一个选项，您可以通过将此参数添加到 java 可执行调用来从运行时排除导致崩溃的方法 -XX:CompileCommand=exclude,com/path/to/class/in/Jar$InnerClassIfAny.methodName

导致崩溃的类和方法的名称可以在崩溃报告（hs_err_pidxxxx.log）上面找到

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

标记。

注意：在 Unix 环境中，内部类（如果有）应该像 \$ 而不是 $ 那样转义。

【讨论】：