tomcat莫名其妙崩潰了，但是也沒有生成hs_err_<pid>.log日誌，但是生成了core日誌，tomcat的日誌下邊只報了一下邊的錯誤：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xff1d7e48, pid=24649, tid=113
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) Server VM (24.80-b11 mixed mode solaris-sparc )
# Problematic frame:
# C [libc.so.1+0x57e48]# [ timer expired, abort... ]
C一般指的是調用本地代碼引起的問題，比如JNI，之後排除了是因爲調用圖片庫jmagick庫引起的，這個庫會調用動態庫。那麼這個問題是什麼原因引起的，經過分析了JVM的C/C++源碼，畫了張流程圖，如下：
這裏做下簡單說明：
2：JVM是運行在操作系統上，比如這裏是Solaris操作系統上，則JVM啓動時候註冊了操作系統底層的信號處理方法，這些信號一般是內存溢出等信號，操作系統負責直接和物理內存打交道，因此在啓動在捕獲到這些問題時，會把這些錯誤信號拋給應用程序；
3：JVM的WatchThread隨着JVM啓動，其定時會被喚醒來檢測JVM的運行情況，比如其觀察一個致命錯誤標誌全局變量，這個變量一旦出現問題，則JVM在調用信號處理方法進行處理時，WatchThread也會在後臺監聽，防止致命錯誤方法處理線程自己出現死鎖等問題，這個進程會等待2分鐘，然後直接kill調JVM；
4：我們的程序調用底層的JNI庫出現內存溢出等問題，被操作系統捕獲到，操作系統會拋出這個信號給JVM，JVM捕捉到後處理；
5：JVM錯誤處理線程設置全局致命錯誤標誌位true，並且籌備打印hs_err_<pid>.log日誌，不過這個線程在做這個事情的過程中，有可能自己也會崩潰，比如非法訪問內存，他自己崩潰後又再次觸發操作系統拋信號，然後再用一個新的JVM致命錯誤線程處理方法來處理這個信號錯誤，如果再次出現錯誤，則會重複捕獲處理，重複拋出，直到遇到死鎖；
6：與此同時，WatchThread在背後冷冷地注視着這一切，當他老人家發現全局致命錯誤日誌爲true時，他老人家只會等待2分鐘，然後kill掉JVM。
注意，在上邊的情況下，就會出現hs_err_<pid>.log也不會被打印出來的問題，但是這個情況下會生成core日誌，因此我們可以使用gdb命令來分析core日誌，關於core日誌的作用是什麼，他是JVM崩潰瞬間的內存快照，至於其他更詳細的資料，大家自己查，這裏不再贅述。
這裏粘貼下JVM的C/C++部分關鍵源碼，如圖：
A：這個圖是在Thread.cpp文件中，是WatchThread類中的代碼：
B：下圖是打日誌的函數，在vmError.cpp文件中：
C：下圖是信號錯誤處理函數，也在vmError.cpp文件中，如圖：
至於其他註冊信號處理方法的類，大家看那副流程圖即可，雖然我畫的很差勁。
發生這個hs_err_<pid>.log日誌沒有生成的問題是，這個錯誤處理線程在寫日誌的時候，由於要申請內存和鎖，而再次引起內存錯誤，進而引起操作系統再次拋出SIGSEGV錯誤，這個時候一個新的線程和當前這個寫日誌的線程出現死鎖或者是出現連鎖反應一直拋出SIGSEGV而導致處理時間超過了2分鐘，最終被WatchThread幹掉整個JVM的問題引起的。
有的時候生成hs_err_<pid>.log文件後，一般不會再生成core文件。有的資料說這是因爲操作系統認爲程序已經捕獲到該異常，因此操作系統自己不會再dump出core日誌，相反如果生成hs_err_<pid>.log失敗，操作系統會認爲應用沒有處理這個錯誤信號，則自己會生成一個core文件，這個還需要再進一步看JVM的源碼，由於時間問題，打算將來再去看這些源碼，有興趣的人可以研究後給我留言，這方面資料網上極其匱乏，這裏把研究心得分享出來，供大家參考。