CoreDump錯誤相關資料

1.1. coredump錯誤除錯

1.1.1. 關鍵字

coredump、除錯

1.1.2. 程式coredump的原因有那些？

程式產生coredump實際上是程序收到sigbus（訊號10）或sigse**（訊號11）訊號而產生的記憶體轉儲，即匯流排錯誤或記憶體侵犯。

匯流排錯誤是訪問記憶體操作偏移量不正確造成的，比較典型的是結構變數成員操作時，偏移量錯誤。

應用程式coredump一般情況都是由記憶體侵犯造成的，以下列出了一些可能發生coredump原因：

 對指標變數的使用錯誤，如沒有申請空間等即操作指標變數；

 由於給字串變數賦值時，給定的字串超過了字串變數的最大儲存空間；

 在函式中的整型變數沒有賦初值，對於用這個變數操作字串陣列，超出陣列最大維數，引起記憶體侵犯；

 64位環境中，int型和long型位元組數不一樣，不能再使用int型別變數的位址作為long指標；

 呼叫函式引數個數不符，最典型的是printf中的s%、d%等和後面的變數不匹配；

 通訊包的格式轉換函式使用不當導致越界；

 採用封裝函式時，用整型儲存資料庫函式count，引起越界，應該用double類儲存。

1.1.3. 怎樣知道是那個程式產生的core檔案？

core檔案一般產生在執行程式存放的目錄下或程式執行時的當前路徑。

具體可使用strings命令可以看到是那個程式產生的core檔案，coredown的程式的名字在core檔案的第一屏顯示；使用file、及dbxtra、xdb、gdb也都可以檢視。

1.1.4. 解決coredump問題最重要的工作是什麼？

是重現該coredump問題。如果能重現，該問題就基本解決了90%，下一步的工作就是基於重現的基礎，逐步縮小問題範圍，最終問題就可以自動顯現出來了。如果不能重現，那即使修改了你認為錯誤的地方，也不能完全保障，問題已經被解決。

1.1.5. 如何利用程式產生的core檔案來進行查錯？

可利用dbxtra來檢視coredump發生的大體位置，方法如下：

在core檔案存在的目錄下使用「dbxtra 《執行程式》」，可看到提示「[using memory image in core]」，使用dbxtra的「t」命令可看到程式執行到的最後乙個函式，可以此確定coredump發生的位置。還可用「p」命令打出當時的變數的值來。

但也有情況是使用dbxtra的「t」命令後顯示「possible stack frame corruption; text address is 0x8047765」表示記憶體侵犯比較嚴重，記憶體轉儲中未能存放函式呼叫的堆疊，只能以其他方式來查詢錯誤。

這裡需要指出的是：coredump發生的位置往往不是記憶體侵犯發生的位置，一般是在此之前的記憶體侵犯造成後面程式侵犯到程式資料段以外空間。查詢coredump問題時一定要注意這一點。

1.1.6. 程式core dump後一定會產生檔案嗎？

不一定，是否產生core檔案與以下條件有關：

1．不同unix作業系統及相應的設定

2．發生coredump的應用程式及其執行時的具體情況

1.1.7. 發生coredump時，如何區分是應用**問題還是平台問題？

在使用平台的應用開發過程中，經常會發生dta/ala程式記憶體洩漏、coredump的情況。

發生這些問題時，首先應定義問題，對問題有初步判斷，想辦法重現問題。