致命錯(cuò)誤出現(xiàn)的時(shí)候，JVM生成了hs_err_pid<pid>.log這樣的文件，其中往往包含了虛擬機(jī)崩潰原因的重要信息。因?yàn)榻?jīng)常遇 到，在這篇文章里，我挑選了一個(gè)，并且逐段分析它包含的內(nèi)容（文件可以在文章最后下載）。默認(rèn)情況下文件是創(chuàng)建在工作目錄下的（如果沒(méi)權(quán)限創(chuàng)建的話JVM 會(huì)嘗試把文件寫(xiě)到/tmp這樣的臨時(shí)目錄下面去），當(dāng)然，文件格式和路徑也可以通過(guò)參數(shù)指定，比如：

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

這個(gè)文件將包括：

  • 觸發(fā)致命錯(cuò)誤的操作異常或者信號(hào)；
  • 版本和配置信息；
  • 觸發(fā)致命異常的線程詳細(xì)信息和線程棧；
  • 當(dāng)前運(yùn)行的線程列表和它們的狀態(tài)；
  • 堆的總括信息；
  • 加載的本地庫(kù)；
  • 命令行參數(shù)；
  • 環(huán)境變量；
  • 操作系統(tǒng)CPU的詳細(xì)信息。

首先，看到的是對(duì)問(wèn)題的概要介紹：

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

一個(gè)非預(yù)期的錯(cuò)誤被JRE檢測(cè)到，其中：

  • SIGSEGV是信號(hào)名稱(chēng)
  • 0xb是信號(hào)碼
  • pc=0x03568cf4指的是程序計(jì)數(shù)器的值
  • pid=16819是進(jìn)程號(hào)
  • tid=3073346448是線程號(hào)

如果你對(duì)JVM有了解，應(yīng)該不會(huì)對(duì)這些東西陌生。

接下來(lái)是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 ) 

運(yùn)行在mixed模式下。

然后是問(wèn)題幀的信息：

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

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

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

當(dāng)前線程的：

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

這部分是導(dǎo)致虛擬機(jī)終止的非預(yù)期的信號(hào)信息，含義前面已經(jīng)大致提到過(guò)了。其中si_errno和si_code是Linux下用來(lái)鑒別異常的，Windows下是一個(gè)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 

棧頂程序計(jì)數(shù)器旁的操作碼，它們可以被反匯編成系統(tǒng)崩潰前執(zhí)行的指令。

  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 

寄存器和內(nèi)存映射信息。

  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 

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

  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) 

虛擬機(jī)狀態(tài)。包括：

  • not at a safepoint：正常運(yùn)行狀態(tài)；
  • at safepoint：所有線程都因?yàn)樘摂M機(jī)等待狀態(tài)而阻塞，等待一個(gè)虛擬機(jī)操作完成；
  • synchronizing：一個(gè)特殊的虛擬機(jī)操作，要求虛擬機(jī)內(nèi)的其它線程保持等待狀態(tài)。
  1. VM Mutex/Monitor currently owned by a thread: None 

虛擬機(jī)的Mutex和Monitor目前沒(méi)有被線程持有。Mutex是虛擬機(jī)內(nèi)部的鎖，而Monitor則關(guān)聯(lián)到了Java對(duì)象。

  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) 

堆信息。新生代、老生代、永久代。對(duì)JVM有了解的人應(yīng)該都清楚，不解釋了。

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

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

  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. ... ... 

內(nèi)存映射。這些信息是虛擬機(jī)崩潰時(shí)的虛擬內(nèi)存列表區(qū)域。在定位崩潰原因的時(shí)候，它可以告訴你哪些類(lèi)庫(kù)正在被使用，位置在哪里，還有堆棧和守護(hù)頁(yè)信息。就以列表中第一條為例說(shuō)明：

  • 00101000-00122000：內(nèi)存區(qū)域
  • r-xp：權(quán)限，r/w/x/p/s分別表示讀/寫(xiě)/執(zhí)行/私有/共享
  • 00000000：文件內(nèi)的偏移量
  • 08:01：文件位置的majorID和minorID
  • 3483560：索引節(jié)點(diǎn)號(hào)
  • /usr/lib/libjpeg.so.62.0.0：文件位置

每一個(gè)lib都有兩塊虛擬內(nèi)存區(qū)域——代碼和數(shù)據(jù)，它們的權(quán)限不同，代碼區(qū)域是r-xp；數(shù)據(jù)區(qū)域是rwxp。守護(hù)頁(yè)（guard page）由權(quán)限為--xp和rwxp的一對(duì)組成。

  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 

虛擬機(jī)參數(shù)和環(huán)境變量。

  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. ... ... 

信號(hào)句柄。對(duì)于Linux下的信號(hào)機(jī)制，參閱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 人發(fā)表留言，猛擊->> 這里<<-參與討論 


ITeye推薦 


相關(guān) [jvm 錯(cuò)誤 日志] 推薦：

JVM致命錯(cuò)誤日志（hs_err_pid.log）解讀

- - 四火的嘮叨
文章系本人原創(chuàng)，轉(zhuǎn)載請(qǐng)保持完整性并注明出自 《四火的嘮叨》. 致命錯(cuò)誤出現(xiàn)的時(shí)候，JVM生成了hs_err_pid<pid>.log這樣的文件，其中往往包含了虛擬機(jī)崩潰原因的重要信息. 因?yàn)榻?jīng)常遇到，在這篇文章里，我挑選了一個(gè)，并且逐段分析它包含的內(nèi)容（文件可以在文章最后下載）. 默認(rèn)情況下文件是創(chuàng)建在工作目錄下的（如果沒(méi)權(quán)限創(chuàng)建的話JVM會(huì)嘗試把文件寫(xiě)到/tmp這樣的臨時(shí)目錄下面去），當(dāng)然，文件格式和路徑也可以通過(guò)參數(shù)指定，比如：.

Fatal Error log format，JVM 致命錯(cuò)誤日志格式

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

JVM日志和參數(shù)的理解

- - 開(kāi)源軟件 - ITeye博客
轉(zhuǎn)自：http://hot66hot.iteye.com/blog/2075819. 寫(xiě)這篇wiki的目的:最近在調(diào)整Hbase的JVM,翻了些文檔和wiki,想寫(xiě)點(diǎn)東西,給自己和想了解jvm日志和參數(shù)的同 學(xué)提供些幫助..  一:理解GC日志格式,讀GC日志的方法. -XX:+UseGCLogFileRotation  啟用GC日志文件的自動(dòng)轉(zhuǎn)儲(chǔ) (Since Java).

通過(guò)JVM日志來(lái)進(jìn)行安全點(diǎn)分析

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

【體系結(jié)構(gòu)】MySQL 日志文件--錯(cuò)誤日志

- - CSDN博客數(shù)據(jù)庫(kù)推薦文章
        記錄MySQL Server 啟動(dòng)和關(guān)閉的詳細(xì)信息、以及運(yùn)行過(guò)程中較為嚴(yán)重的警告和錯(cuò)誤信息.        為了維護(hù)方便需要、有時(shí)候會(huì)希望將錯(cuò)誤日志中的內(nèi)容做備份并重新開(kāi)始記錄、那么可以：.         MySQL DBA 在遇到問(wèn)題時(shí)應(yīng)該首先查看該文件.         當(dāng)出現(xiàn) MySQL Server 不能正常啟動(dòng)時(shí)、第一個(gè)拷問(wèn)的重點(diǎn)對(duì)象應(yīng)該就是此人.

Oracle GoldenGate 監(jiān)控工具：ggserr.log 錯(cuò)誤日志不可忽視

- - CSDN博客推薦文章
Oracle 原廠最近在生產(chǎn)環(huán)境的主數(shù)據(jù)庫(kù)安裝了 OEM 12C 的監(jiān)控插件后，主數(shù)據(jù)庫(kù)對(duì)外十幾個(gè)庫(kù)同步同步的. Oracle GoldenGate 實(shí)例出現(xiàn)異常，瘋狂地往 GoldenGate 根目錄的 ggserr.log 輸入出如下錯(cuò)誤日志：. 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研究

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

學(xué)習(xí)JVM的References

- LightingMan - 淘寶JAVA中間件團(tuán)隊(duì)博客
本blog中列舉了我學(xué)習(xí)JVM的references，會(huì)不斷的更新，為了避免版權(quán)問(wèn)題，就不在blog上提供references的下載了，感興趣的同學(xué)可自行下載或購(gòu)買(mǎi)，:). |— [ Hotspot GC論文 ]. |— [ 其他JVM GC ]. |— Linux內(nèi)核源代碼情景分析. |— Linux 內(nèi)核中斷內(nèi)幕.

深入理解JVM

- 小偉 - ITeye論壇最新討論
1   Java技術(shù)與Java虛擬機(jī). 說(shuō)起Java，人們首先想到的是Java編程語(yǔ)言，然而事實(shí)上，Java是一種技術(shù)，它由四方面組成: Java編程語(yǔ)言、Java類(lèi)文件格式、Java虛擬機(jī)和Java應(yīng)用程序接口(Java API). 圖1   Java四個(gè)方面的關(guān)系. 運(yùn)行期環(huán)境代表著Java平臺(tái)，開(kāi)發(fā)人員編寫(xiě)Java代碼(.java文件)，然后將之編譯成字節(jié)碼(.class文件).