JVM崩溃有问题的框架：Canonicalizer :: do_If

荫面向JVM崩溃cosistently同时使hotdeploy（上启动JAVA_OPTS -Xmx4096m -XX使用以下Java选项：MetaspaceSize =512米-XX：+ HeapDumpOnOutOfMemoryError -XX：HeapDumpPath =崩溃 - 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，暂停= N -XX：NewRatio = 2 -Dspringloaded.synchronize =真JAVA_OPTS =`回声$ JAVA_OPTS -Dspringloaded.synchronize =真-javaagent：弹簧式-1.2.1.jar -noverify ）JVM崩溃有问题的框架：Canonicalizer :: do_If

环境：JDK 1.8 U 66，RHEL 6.7

 

    # 
    # A fatal error has been detected by the Java Runtime Environment: 
    # 
    # SIGSEGV (0xb) at pc=0x00007faee9a1e27c, pid=27208, tid=140379827795712 
    # 
    # JRE version: Java(TM) SE Runtime Environment (8.0_66-b17) (build 1.8.0_66-b17) 
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode linux-amd64) 
    # Problematic frame: 
    # V [libjvm.so+0x35027c] Canonicalizer::do_If(If*)+0x1c 
    # 
    # Core dump written. Default location: core.27208 
    # 
    # An error report file with more information is saved as: 
    # hs_err_pid27208.log 
    # [ timer expired, abort... ]

来源

2016-10-29 sailukar

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

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

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

-XX:-TieredCompilation也可能会解决此特定问题，但不要期望应用程序在字节码无法通过验证时正常工作。最好远离错误代理库。

来源

2016-10-29 16:55:29 apangin

感谢您的快速回复，如果我启用字节码校验器有几个问题，现在是否有任何其他解决方法。 – sailukar

如果您的代码在字节码验证程序下失败，那么您已经有问题。你只是通过禁用它来延迟发生的错误。 – the8472

@ user3895269尝试'-XX：-TieredCompilation'。它可能会解决此问题，但如果字节码未能通过验证，则不要期望应用程序正常工作。最好远离错误代理库。 – apangin

4.2.1热点编译器线程崩溃或编译代码

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

对于HotSpot Client VM（-client选项），编译器线程作为CompilerThread0出现在错误日志中。使用HotSpot 服务器虚拟机有多个编译器线程，并且这些线程将作为CompilerThread0，CompilerThread1和AdapterThread出现在错误日志文件中。

下面是在J2SE 5.0开发过程中碰到并修复的编译器错误的错误日志片段。日志文件显示使用HotSpot服务器虚拟机并在编译器线程1 中发生崩溃。另外，日志文件显示当前编译任务是编译java.lang.Thread.setPriority 方法。

HotSpot虚拟机检测到意外错误：： Java VM：Java HotSpot™服务器虚拟机（1。5内部调试混合模式）： --------------- THREAD ---------------

当前线程（0x001e9350）：JavaThread “CompilerThread1” 守护程序 [_thread_in_vm，ID = 20]

堆栈：[0xb2500000,0xb2580000），SP = 0xb257e500，自由空间= 505K 本地帧：（J =编译的Java代码，J =解释，VV = VM代码， C =本地代码）V [libjvm.so + 0xc3b13c]：

电流CompileTask：光电：11 java.lang.Thread.setPriority（I）V （53个字节）

--------------- PROCESS ---------------

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 
客户端VM。
Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation. 
第一种方法（使用-client选项）可能是微不足道的在某些环境配置。在其他情况下，如果配置比较复杂，或者配置虚拟机的命令行不易访问，则可能会更困难。。通常，从HotSpot Server VM切换到HotSpot Client VM也会降低应用程序的性能峰值。取决于环境，这个可能是可以接受的，直到实际问题被诊断并修复。

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

排除的java /郎/螺纹setPriority

通常该文件的格式是排除类方法，其中 CLASS是类（具有包名称完全限定）和方法是该方法的名称。构造函数方法被指定为，静态初始值设定项指定为。

注 - .hotspot_compiler文件是不受支持的界面。这里记录的是，仅用于排除故障并找到的临时解决方法。

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

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

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

Source

来源

2017-03-24 13:45:55 LoveOfGod

与@apangin同意，在程序中，你正在做的字节码intrumentation（-agent），但规定-noverify。当验证关闭时，您可能会导致此类崩溃。

在字节码操作期间，您不应该使用-noverify或-Xverify：none。

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

来源

2017-04-23 06:06:50 Fairoz

JVM崩溃有问题的框架：Canonicalizer :: do_If

回答

相关问题