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

回答

相關問題