Linux開發coredump檔案分析實戰分享

前言：

#在嵌入式Linux開發中，分析coredump檔案是常用的方法，我們經常可以在網路上找到相關的使用教學。然而，很少有介紹如何分析多執行緒應用程式的coredump檔案的文章。今天我來分享一些實際使用上遇到的案例，希望能提供給大家一些幫助。由於程式碼和篇幅的限制，我只會描述我認為比較有特色的問題，並以框架思維去解決許多遇到的coredump檔案的情況。

作者：良知猶存

轉載授權與圍觀：歡迎關注微信公眾號：羽林君

或新增作者個人微信：become_me

---

#劇情介紹:

在偵錯一個功能時，我產生了一些coredump文件，並且出現了不同的程式報錯情況。透過這個機會，我想分享給大家。一般而言，coredump檔案產生的原因可能是空指標、陣列越界、多執行緒多次釋放、堆疊溢位等等。 在這裡我按照自己遇到的情況挑選了一些代表性的問題，與大家分享一些簡單的解決想法。

首先，要進行對應的偵錯，我們需要使用gdb工具。在開始分析coredump檔案之前，需要先熟悉gdb的各個指令。以下是我之前寫的兩篇關於gdb調試的文章：

一文入門Linux下gdb調試(一)

一文入門Linux下gdb調試(二)

因此，本文將不再贅述這些內容，只著重在分析coredump檔案時，我們需要進行的實際操作。

首先，我們需要使用具有偵錯資訊的可執行檔進行偵錯。

gdb executable_file coredump_file

範例一：指標初始化失敗

進入之後第一件事就是 使用 bt指令查看堆疊資訊

在這個coredump檔案中，我們很容易看到一個函數的傳入位址和類別成員函數有明顯的資料差異。如此明顯的部分我們就可以直接下定論之後，進行細節檢視。

f  n 

透過幀編號來選擇幀，幀編號可以透過 bt 指令來查看。

我们查看对应的第 17帧的堆栈信息

通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。

为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息

然后我们需要确认该指针是什么什么出现问题的，进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系，确认gyro_在这个函数执行的时候，地址是否正确。

从上面来看在此处函数执行的时候，对应的gyro的地址还没有变成错误的0x1388。

从这里我们基本可以确认到，函数从 第20帧对应位置执行之后再到17帧的函数的时候，执行函数的地址发生了改变 然后开始进入校对代码的环节。

这个时候校对不是看代码执行的具体情况，因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。

最终找到了一个出现线程调用先后顺序导致变量没有准备好，出现的死机情况。

示例二：另一个指针问题

进入之后第一件事情 使用 bt命令查看堆栈信息

这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。

这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。

thread apply all bt

除了bt大家也可以打印自己需要的其他信息

thread apply all command //所有线程都执行命令

对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。

此时我们发现led一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个bug。

示例三：内存溢出

进入之后第一件事情 使用 bt命令查看堆栈信息

此时发现当前堆栈信息也无法进行定位到问题。

然後我們使用了thread apply all bt 但是第一遍我們沒有看到對應的hand_exit函數

然後我們使用 info locals來查看保存的本地變數的資訊

 

info f addr列印透過addr指定幀的資訊。 info args列印函數變數的值。

info locals 列印本地變數的資訊。

info catch列印出目前的函數中的異常處理資訊。

本地變數也沒有一些明顯表示指標錯誤、資料越界的一些顯示。

所以 我們又使用 p 指令列印幀資訊裡面保存的變數資訊。

透過列印這些我們認為出錯率比較高的變數訊息，可以輔助我們進行判斷。不過本次列印也沒辦法確認到問題位置。

然後我們重新看全部執行緒的堆疊資訊。最後看到了一個異常的參數，這個值很大，有些異常。

緊接著我們進行查看對應的原始碼位置，因為是C 的函式庫，所以我們直接看編譯位置的程式碼。

先看 第7 幀 訊息顯示的stl_algobase.h:465

開啟對應的代碼位置之後發現**__n**參數 是進行分配空間的數量的參數。

再次查看執行前後的 stl_vector.h:343

#

而現在傳入的__n大約是大於億的單位值，而程式碼實際工作的位置是不需要這麼大的空間分配的。所以確認是這裡有問題，對照程式碼執行的位置以及對應變數的全域使用情況，最後基本定性為佇列在多執行緒使用中，鎖沒有使用好，導致多個執行緒在極端情況下，輸出和輸入操作會對同一個區域進行，導致了這次代碼死機。

結語

這是我分享的專案中分析coredump檔案的狀況，如果大家有更好的想法和需求，也歡迎大家加我好友交流分享哈。

此外除了我文中使用的這些指令，大家也可以輔助gbd調試的更多指令來檢查我們coredump檔。例如查看彙編程式碼等等。網路上關於gdb調試指令的文章還是很多，大家也可以輔助看其他文章指令使用。

以上是Linux開發coredump檔案分析實戰分享的詳細內容。更多資訊請關注PHP中文網其他相關文章！