致命錯誤出現的時候，JVM生成了hs_err_pid<pid>.log這樣的文件，其中往往包含了虛擬機崩潰原因的重要信息。因為經常遇 到，在這篇文章里，我挑選了一個，并且逐段分析它包含的內容（文件可以在文章最后下載）。默認情況下文件是創建在工作目錄下的（如果沒權限創建的話JVM 會嘗試把文件寫到/tmp這樣的臨時目錄下面去），當然，文件格式和路徑也可以通過參數指定，比如：

  1. java -XX:ErrorFile=/var/log/java/java_error%p.log 

這個文件將包括：

  • 觸發致命錯誤的操作異常或者信號；
  • 版本和配置信息；
  • 觸發致命異常的線程詳細信息和線程棧；
  • 當前運行的線程列表和它們的狀態；
  • 堆的總括信息；
  • 加載的本地庫；
  • 命令行參數；
  • 環境變量；
  • 操作系統CPU的詳細信息。

首先，看到的是對問題的概要介紹：

  1. #  SIGSEGV (0xb) at pc=0x03568cf4, pid=16819, tid=3073346448 

一個非預期的錯誤被JRE檢測到，其中：

  • SIGSEGV是信號名稱
  • 0xb是信號碼
  • pc=0x03568cf4指的是程序計數器的值
  • pid=16819是進程號
  • tid=3073346448是線程號

如果你對JVM有了解，應該不會對這些東西陌生。

接下來是JRE和JVM的版本信息：

  1. # JRE version: 6.0_32-b05 
  2.   
  3. # Java VM: Java HotSpot(TM) Server VM (20.7-b02 mixed mode linux-x86 ) 

運行在mixed模式下。

然后是問題幀的信息：

  1. # Problematic frame: 
  2.   
  3. # C  [libgtk-x11-2.0.so.0+0x19fcf4]  __float128+0x19fcf4 
  • C：幀類型為本地幀，幀的類型包括： 
    • C：本地C幀
    • j：解釋的Java幀
    • V：虛擬機幀
    • v：虛擬機生成的存根棧幀
    • J：其他幀類型，包括編譯后的Java幀
  • libgtk-x11-2.0.so.0+0x19fcf4：和程序計數器（pc）表達的含義一樣，但是用的是本地so庫+偏移量的方式。

接下去第一部分是線程信息：

  1. Current thread (0x09f30c00):  JavaThread "main" [_thread_in_native, id=16822, stack(0xb72a8000,0xb72f9000)] 

當前線程的：

  • 0x09f30c00：指針
  • JavaThread：線程類型，可能的類型包括： 
    • JavaThread
    • VMThread
    • CompilerThread
    • GCTaskThread
    • WatcherThread
    • ConcurrentMarkSweepThread
  • main：名字 
    • _thread_in_native：線程當前狀態，狀態枚舉包括：
    • _thread_uninitialized：線程還沒有創建，它只在內存原因崩潰的時候才出現
    • _thread_new：線程已經被創建，但是還沒有啟動
    • _thread_in_native：線程正在執行本地代碼，一般這種情況很可能是本地代碼有問題
    • _thread_in_vm：線程正在執行虛擬機代碼
    • _thread_in_Java：線程正在執行解釋或者編譯后的Java代碼
    • _thread_blocked：線程處于阻塞狀態
    • …_trans：以_trans結尾，線程正處于要切換到其它狀態的中間狀態
  • id=16822：線程ID
  • 0xb72a8000,0xb72f9000：棧區間
  1. siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000010 

這部分是導致虛擬機終止的非預期的信號信息，含義前面已經大致提到過了。其中si_errno和si_code是Linux下用來鑒別異常的，Windows下是一個ExceptionCode。

  1. EAX=0x00000000, EBX=0x0375dd84, ECX=0x00000000, EDX=0x00000000 
  2. ESP=0xb72f0fa0, EBP=0xb72f0fb8, ESI=0x00000000, EDI=0x0a6c1800 
  3. EIP=0x03568cf4, EFLAGS=0x00010246, CR2=0x00000010 

這是寄存器上下文。

 

  1. Top of Stack: (sp=0xb72f0fa0) 
  2. 0xb72f0fa0:   00000000 00402250 0040217f 0375dd84 
  3. 0xb72f0fb0:   00000000 0a6c1800 b72f0fe8 0356c2c0 
  4. 0xb72f0fc0:   00000000 0a6c1800 b72f0fe8 003b3e77 
  5. 0xb72f0fd0:   003e6c8b 0a1a70d0 0a193358 0375dd84 
  6. 0xb72f0fe0:   0a276418 0a276418 b72f1048 03536c56 
  7. 0xb72f0ff0:   0acad000 0b3ca978 0000000c 00dd0674 
  8. 0xb72f1000:   00000003 0a2c7d50 b72f1038 0000330c 
  9. 0xb72f1010:   ffffffff ffffffff 00000001 00000001 
  10.   
  11. Instructions: (pc=0x03568cf4) 
  12. 0x03568cd4:   89 14 24 89 75 f8 89 d6 89 7d fc 89 c7 e8 7e 1b 
  13. 0x03568ce4:   ea ff 89 34 24 89 87 d4 02 00 00 e8 30 00 ea ff 
  14. 0x03568cf4:   8b 40 10 89 3c 24 c7 44 24 08 00 00 00 00 89 87 
  15. 0x03568d04:   d0 02 00 00 8b 83 88 24 00 00 89 44 24 04 e8 dd 

棧頂程序計數器旁的操作碼，它們可以被反匯編成系統崩潰前執行的指令。

  1. Register to memory mapping: 
  2.   
  3. EAX=0x00000000 is an unknown value 
  4. EBX=0x0375dd84: <offset 0x394d84> in /usr/lib/libgtk-x11-2.0.so.0 at 0x033c9000 
  5. ECX=0x00000000 is an unknown value 
  6. EDX=0x00000000 is an unknown value 
  7. ESP=0xb72f0fa0 is pointing into the stack for thread: 0x09f30c00 
  8. EBP=0xb72f0fb8 is pointing into the stack for thread: 0x09f30c00 
  9. ESI=0x00000000 is an unknown value 
  10. EDI=0x0a6c1800 is an unknown value 

寄存器和內存映射信息。

  1. Stack: [0xb72a8000,0xb72f9000],  sp=0xb72f0fa0,  free space=291k 
  2. Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 
  3. C  [libgtk-x11-2.0.so.0+0x19fcf4]  __float128+0x19fcf4 
  4. C  [libgtk-x11-2.0.so.0+0x1a32c0]  __float128+0xc0 
  5. ... ... 
  6. C  [libswt-pi-gtk-3738.so+0x33f6a]  Java_org_eclipse_swt_internal_gtk_OS__1Call+0xf 
  7. J  org.eclipse.swt.internal.gtk.OS._Call(III)I 
  8. J  org.eclipse.swt.internal.gtk.OS.Call(III)I 
  9.   
  10. Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) 
  11. J  org.eclipse.swt.internal.gtk.OS._Call(III)I 
  12. J  org.eclipse.swt.internal.gtk.OS.Call(III)I 
  13. j  org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc(II)I+5 
  14. j  org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(II)I+17 
  15. v  ~StubRoutines::call_stub 

線程棧。包含了地址、棧頂、棧計數器和線程尚未使用的棧信息，由于棧可能非常長，打印的長度有限制，但是至少本地棧和Java棧都打印出來了（很多時候本地棧打印不出來，但是Java棧一般都能打印出來）。從中可以看到，Eclipse的虛擬機崩潰了。

  1. ava Threads: ( => current thread ) 
  2.   0x0b4c1000 JavaThread "Worker-247" [_thread_blocked, id=25417, stack(0x741bc000,0x7420d000)] 
  3.   0x0a300c00 JavaThread "Worker-246" [_thread_blocked, id=25235, stack(0x7d30c000,0x7d35d000)] 
  4. ... ... 

線程信息。一目了然，不解釋了。

  1. VM state:not at safepoint (normal execution) 

虛擬機狀態。包括：

  • not at a safepoint：正常運行狀態；
  • at safepoint：所有線程都因為虛擬機等待狀態而阻塞，等待一個虛擬機操作完成；
  • synchronizing：一個特殊的虛擬機操作，要求虛擬機內的其它線程保持等待狀態。
  1. VM Mutex/Monitor currently owned by a thread: None 

虛擬機的Mutex和Monitor目前沒有被線程持有。Mutex是虛擬機內部的鎖，而Monitor則關聯到了Java對象。

  1. Heap 
  2.  PSYoungGen      total 149056K, used 125317K [0xa9700000, 0xb41a0000, 0xb41a0000) 
  3.   eden space 123520K, 95% used [0xa9700000,0xb0ac0de0,0xb0fa0000) 
  4.   from space 25536K, 26% used [0xb28b0000,0xb2f50748,0xb41a0000) 
  5.   to   space 25600K, 0% used [0xb0fa0000,0xb0fa0000,0xb28a0000) 
  6.  PSOldGen        total 261248K, used 239964K [0x941a0000, 0xa40c0000, 0xa9700000) 
  7.   object space 261248K, 91% used [0x941a0000,0xa2bf7018,0xa40c0000) 
  8.  PSPermGen       total 163328K, used 130819K [0x841a0000, 0x8e120000, 0x941a0000) 
  9.   object space 163328K, 80% used [0x841a0000,0x8c160c40,0x8e120000) 

堆信息。新生代、老生代、永久代。對JVM有了解的人應該都清楚，不解釋了。

  1. Code Cache  [0xb4262000, 0xb5ac2000, 0xb7262000) 
  2.  total_blobs=5795 nmethods=5534 adapters=209 free_code_cache=25103616 largest_free_block=38336 

代碼緩存（Code Cache）。這是一塊用于編譯和保存本地代碼的內存，注意是本地代碼，它和PermGen（永久代）是不一樣的，永久帶是用來存放Java類定義的。

  1. Dynamic libraries: 
  2. 00101000-00122000 r-xp 00000000 08:01 3483560    /usr/lib/libjpeg.so.62.0.0 
  3. 00122000-00123000 rwxp 00020000 08:01 3483560    /usr/lib/libjpeg.so.62.0.0 
  4. 00125000-00130000 r-xp 00000000 08:01 9093202    /lib/libgcc_s-4.1.2-20080825.so.1 
  5. 00130000-00131000 rwxp 0000a000 08:01 9093202    /lib/libgcc_s-4.1.2-20080825.so.1 
  6. ... ... 

內存映射。這些信息是虛擬機崩潰時的虛擬內存列表區域。在定位崩潰原因的時候，它可以告訴你哪些類庫正在被使用，位置在哪里，還有堆棧和守護頁信息。就以列表中第一條為例說明：

  • 00101000-00122000：內存區域
  • r-xp：權限，r/w/x/p/s分別表示讀/寫/執行/私有/共享
  • 00000000：文件內的偏移量
  • 08:01：文件位置的majorID和minorID
  • 3483560：索引節點號
  • /usr/lib/libjpeg.so.62.0.0：文件位置

每一個lib都有兩塊虛擬內存區域——代碼和數據，它們的權限不同，代碼區域是r-xp；數據區域是rwxp。守護頁（guard page）由權限為--xp和rwxp的一對組成。

  1. VM Arguments: 
  2. jvm_args: -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms40m -Xmx512m -Dorg.eclipse.swt.browser.XULRunnerPath='' 
  3. java_command: /.../eclipse/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -os linux -ws gtk -arch x86 -showsplash -launcher /.../eclipse/eclipse -name Eclipse ... 
  4. Launcher Type: SUN_STANDARD 
  5.   
  6. Environment Variables: 
  7. PATH=... 
  8. DISPLAY=:0.0 

虛擬機參數和環境變量。

  1. Signal Handlers: 
  2. SIGSEGV: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 
  3. SIGBUS: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 
  4. ... ... 

信號句柄。對于Linux下的信號機制，參閱wiki百科， 鏈接。

 

  1. OS:Red Hat Enterprise Linux Client release 5.4 (Tikanga) 
  2.   
  3. uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:54 EDT 2009 i686 
  4. libc:glibc 2.5 NPTL 2.5 
  5. rlimit: STACK 10240k, CORE 0k, NPROC 65536, NOFILE 1024, AS infinity 
  6. load average:1.78 1.58 1.54 
  7.   
  8. /proc/meminfo: 
  9. ... 
  10.   
  11. CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 
  12.   
  13. /proc/cpuinfo: 
  14. ... 
  15.   
  16. Memory: 4k page, physical 3631860k(155144k free), swap 5124724k(5056452k free) 


已有 0 人發表留言，猛擊->> 這里<<-參與討論 


ITeye推薦 


相關 [jvm 錯誤 日志] 推薦：

JVM致命錯誤日志（hs_err_pid.log）解讀

- - 四火的嘮叨
文章系本人原創，轉載請保持完整性并注明出自 《四火的嘮叨》. 致命錯誤出現的時候，JVM生成了hs_err_pid<pid>.log這樣的文件，其中往往包含了虛擬機崩潰原因的重要信息. 因為經常遇到，在這篇文章里，我挑選了一個，并且逐段分析它包含的內容（文件可以在文章最后下載）. 默認情況下文件是創建在工作目錄下的（如果沒權限創建的話JVM會嘗試把文件寫到/tmp這樣的臨時目錄下面去），當然，文件格式和路徑也可以通過參數指定，比如：.

Fatal Error log format，JVM 致命錯誤日志格式

- - 碼蜂筆記
本文翻譯自： http://www.oracle.com/technetwork/java/javase/felog-138657.html. 本文內容基于 Java SE 6，HotSpot JVM. 當一個致命錯誤發生時，一個錯誤日志將被創建，存儲了在致命錯誤發生時獲取到的信息和狀態. 注意：這個文件的格式可能隨著版本的更新而改變.

JVM日志和參數的理解

- - 開源軟件 - ITeye博客
轉自：http://hot66hot.iteye.com/blog/2075819. 寫這篇wiki的目的:最近在調整Hbase的JVM,翻了些文檔和wiki,想寫點東西,給自己和想了解jvm日志和參數的同 學提供些幫助..  一:理解GC日志格式,讀GC日志的方法. -XX:+UseGCLogFileRotation  啟用GC日志文件的自動轉儲 (Since Java).

通過JVM日志來進行安全點分析

- - 并發編程網 - ifeve.com
原文鏈接 作者: Plumbr 譯者：之諸暇. 許多事件都可能會導致JVM暫停所有的應用線程. 這類暫停又被稱為”stop-the-world”（STW）暫停. 觸發STW暫停最常見的原因就是垃圾回收了（ github中的一個例子），但不同的JIT活動( 例子)，偏向鎖擦除（ 例子）， 特定的JVMTI操作，以及許多場景也可能會導致應用程序暫停.

【體系結構】MySQL 日志文件--錯誤日志

- - CSDN博客數據庫推薦文章
        記錄MySQL Server 啟動和關閉的詳細信息、以及運行過程中較為嚴重的警告和錯誤信息.        為了維護方便需要、有時候會希望將錯誤日志中的內容做備份并重新開始記錄、那么可以：.         MySQL DBA 在遇到問題時應該首先查看該文件.         當出現 MySQL Server 不能正常啟動時、第一個拷問的重點對象應該就是此人.

Oracle GoldenGate 監控工具：ggserr.log 錯誤日志不可忽視

- - CSDN博客推薦文章
Oracle 原廠最近在生產環境的主數據庫安裝了 OEM 12C 的監控插件后，主數據庫對外十幾個庫同步同步的. Oracle GoldenGate 實例出現異常，瘋狂地往 GoldenGate 根目錄的 ggserr.log 輸入出如下錯誤日志：. 2013-02-22 22:33:26  WARNING OGG-01930  Oracle GoldenGate Capture for Oracle, pcqstqz1.prm:  Datastore error in 'dirbdb': BDB0060 PANIC: fatal region error detected; run recovery.

JVM研究

- - 開源軟件 - ITeye博客
每天接客戶的電話都是戰戰兢兢的，生怕再出什么幺蛾子了. 我想Java做的久一點的都有這樣的經歷，那這些問題的最終根結是在哪呢. JVM全稱是Java Virtual Machine，Java虛擬機，也就是在計算機上再虛擬一個計算機，這和我們使用 VMWare不一樣，那個虛擬的東西你是可以看到的，這個JVM你是看不到的，它存在內存中.

學習JVM的References

- LightingMan - 淘寶JAVA中間件團隊博客
本blog中列舉了我學習JVM的references，會不斷的更新，為了避免版權問題，就不在blog上提供references的下載了，感興趣的同學可自行下載或購買，:). |— [ Hotspot GC論文 ]. |— [ 其他JVM GC ]. |— Linux內核源代碼情景分析. |— Linux 內核中斷內幕.

深入理解JVM

- 小偉 - ITeye論壇最新討論
1   Java技術與Java虛擬機. 說起Java，人們首先想到的是Java編程語言，然而事實上，Java是一種技術，它由四方面組成: Java編程語言、Java類文件格式、Java虛擬機和Java應用程序接口(Java API). 圖1   Java四個方面的關系. 運行期環境代表著Java平臺，開發人員編寫Java代碼(.java文件)，然后將之編譯成字節碼(.class文件).