JVM 崩溃问题框架：Canonicalizer::do_If答案

【问题标题】：JVM Crash Problematic Frame: Canonicalizer::do_IfJVM 崩溃问题框架：Canonicalizer::do_If
【发布时间】：2017-03-12 07:09:13
【问题描述】：

我在启用热部署时始终面临 JVM 崩溃（在启动时使用以下 java 选项 JAVA_OPTS -Xmx4096m -XX:MetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=crash -XX:ThreadStackSize=512 -XX :+UseConcMarkSweepGC -XX:ParallelGCThreads=5 -XX:NewRatio=2 -XX:+UnlockDiagnosticVMOptions -XX:-UseLoopPredicate -Xdebug -Xrunjdwp:transport=dt_socket,address=$DEBUG_PORT,server=y,suspend=n -XX:NewRatio =2 -Dspringloaded.synchronize=true JAVA_OPTS=`echo $JAVA_OPTS -Dspringloaded.synchronize=true -javaagent:springloaded-1.2.1.jar -noverify )

环境：JDK 1.8 U 66，RHEL 6.7

# # Java 运行时环境检测到一个致命错误： # # SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712 # # JRE 版本：Java(TM) SE 运行时环境 (8.0_66-b17) (build 1.8.0_66-b17) # Java 虚拟机：Java HotSpot(TM) 64 位服务器虚拟机（25.66-b17 混合模式 linux-amd64 ） # 有问题的框架： # V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c # # 核心转储写入。默认位置：core.27208 # # 包含更多信息的错误报告文件保存为： # hs_err_pid27208.log # [定时器过期，中止...]

【问题讨论】：

标签： crash jvm canonical-link

【解决方案1】：

我注意到 Java 选项列表中的 -javaagent 和 -noverify。

看起来springloaded 代理生成了无效的字节码，而字节码验证被明确关闭。毫不奇怪，这可能会导致不可预知的结果，包括 JVM 崩溃。

这不是 JVM 问题，但很可能是 springloaded 代理中的错误。尝试删除-noverify 选项。

-XX:-TieredCompilation 也可以解决这个特定问题，但如果字节码未能通过验证，请不要指望应用程序能够正常工作。最好远离有缺陷的代理库。

【讨论】：

感谢您的快速回复，如果我启用字节码验证器有几个问题，现在还有其他解决方法吗。
如果您的代码在字节码验证器下失败，那么您已经遇到了问题。您只是通过禁用它来延迟错误的发生。
@user3895269 试试-XX:-TieredCompilation。它可能会解决这个特定问题，但如果字节码未能通过验证，请不要指望应用程序能够正常工作。最好远离有缺陷的代理库。
谢谢，这有帮助，我也用更新的弹簧替换了弹簧

【解决方案2】：

4.2.1 HotSpot 编译器线程或编译代码崩溃

如果致命错误日志表明崩溃发生在编译器中线程，那么您有可能（但并非总是如此）遇到编译器错误。同样，如果崩溃是在编译那么有可能编译器生成了不正确的代码代码。

对于 HotSpot 客户端 VM（-client 选项），编译器线程在错误日志中显示为 CompilerThread0。使用热点服务器虚拟机有多个编译器线程，这些出现在错误日志文件为 CompilerThread0、CompilerThread1 和 AdapterThread。

以下是编译器错误的错误日志片段在 J2SE 5.0 的开发过程中遇到并修复。日志文件显示使用了 HotSpot Server VM，并且崩溃发生在编译器线程 1。此外，日志文件显示当前 CompileTask 是 java.lang.Thread.setPriority 的编译方法。

HotSpot 虚拟机检测到意外错误：： Java VM：Java HotSpot(TM) Server VM（1.5-internal-debug混合模式）： --------------- T H R E A D ---------------

当前线程 (0x001e9350)：JavaThread "CompilerThread1" 守护进程 [_thread_in_vm, id=20]

堆栈：[0xb2500000,0xb2580000)，sp=0xb257e500，可用空间=505k 本机帧：（J=编译的 Java 代码，j=解释的，Vv=VM 代码， C=本机代码）V [libjvm.so+0xc3b13c]：

当前编译任务：opto: 11 java.lang.Thread.setPriority(I)V （53 字节）

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

Java 线程: (=> 当前线程) 0x00229930 JavaThread "Low 内存检测器”守护进程 [_thread_blocked, id=21] =>0x001e9350 JavaThread "CompilerThread1" 守护进程 [_thread_in_vm, id=20] :

在这种情况下，有两种可能的解决方法：
The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot
客户端虚拟机。
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.
第一种方法（使用 -client 选项）可能是微不足道的在某些环境中配置。在其他情况下，这可能更困难如果配置很复杂，或者如果要配置的命令行 VM 不容易访问。一般来说，从 HotSpot Server VM 到 HotSpot Client VM 也降低了峰值应用程序的性能。根据环境，这在实际问题得到诊断和解决之前可能是可以接受的。

第二种方法（从编译中排除该方法）需要在工作目录中创建文件 .hotspot_compiler 应用。下面是这个文件的一个例子：

排除 java/lang/Thread setPriority

一般来说这个文件的格式是 exclude CLASS METHOD，其中 CLASS 是类（使用包名完全限定）和 METHOD 是方法的名称。构造函数方法被指定为和静态初始化器被指定为。

注意 - .hotspot_compiler 文件是不受支持的接口。它是此处记录仅用于故障排除和查找临时解决方法。

一旦应用程序重新启动，编译器将不会尝试编译 .hotspot_compiler 中排除的任何方法文件。在某些情况下，这可以提供暂时的缓解，直到根诊断出崩溃的原因并修复了错误。

为了验证 HotSpot VM 是否正确定位和处理上面示例中显示的 .hotspot_compiler 文件，看在运行时获取以下日志信息。注意文件名分隔符是一个点，而不是斜线。

不包括编译：java.lang.Thread::setPriority

Source

【讨论】：

【解决方案3】：

同意@apangin，在程序中您正在执行字节码插入（-agent），但指定了-noverify。关闭验证后，您可能会遇到此类崩溃。

在字节码插入期间不应使用 -noverify 或 -Xverify:none。

对于那些不熟悉字节码验证的人来说，它只是 JVM 类加载过程的一部分，用于检查代码是否存在某些危险和不允许的行为。您可以（但不应）通过在 Java 命令行中添加 -Xverify:none 或 -noverify 在许多 JVM 上禁用此保护。 https://blogs.oracle.com/buck/entry/never_disable_bytecode_verification_in

【讨论】：