前言：

coredump 分析是嵌入式linux開發(fā)中經(jīng)常使用的方法，我們也可以經(jīng)?？吹较嚓P(guān)的使用教程，但是網(wǎng)上很少有一個多線程應(yīng)用coredump文件的分析過程介紹，今天我來分享一下自己實際使用中一些案例，來給大家進行一下分享，受限于代碼和篇幅。我此處只描述一些我認(rèn)為比較有特色的問題，工作中遇到很多的coredump文件都可以用這些框架思維去解決。

作者：良知猶存

轉(zhuǎn)載授權(quán)以及圍觀：歡迎關(guān)注微信公眾號：羽林君

或者添加作者個人微信：become_me

情節(jié)介紹:

我在調(diào)試一個功能時候,產(chǎn)生了一些coredump文件 正好出現(xiàn)了不一樣的程序報錯的情況 ，正好借這個機會給大家分享一下。一般coredump文件產(chǎn)生的原因有空指針、數(shù)組越界、多線程多次釋放、堆棧溢出等等。這里我就是按照自己遇到的情況，找了一些比較有代表性的給大家做一個簡單的分享。

首先我們對應(yīng)調(diào)試的話 使用gdb調(diào)試 先得熟悉一下gdb調(diào)試得各個命令，以下兩篇文章是我之前進行g(shù)db工作的描述，

一文入門Linux下gdb調(diào)試(一)

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

所以本文就不多做贅述，只進行對應(yīng)coredump文件分析時候，我們需要進行查看分析的實戰(zhàn)。

首先我們用帶有debug信息的可執(zhí)行文件進行調(diào)試

gdb executable_file coredump_file

示例一：指針初始化失敗

進入之后第一件事情就是 使用 bt命令查看堆棧信息

在這個coredump文件中，我們很容易看到一個函數(shù)的傳入地址和類成員函數(shù)有明顯的數(shù)據(jù)區(qū)別。如此明顯的部分我們就可以直接下定論之后，進行細(xì)節(jié)查看。

f  n
通過幀編號來選擇幀，幀編號可以通過 bt 命令來查看。

我們查看對應(yīng)的第 17幀的堆棧信息

通過上面截圖我們可以看到在第17幀中 this這個類實體化的地址出現(xiàn)了問題。

為了對比我們又查看了對應(yīng)20幀的堆棧信息以及對應(yīng)幀的詳細(xì)信息

然后我們需要確認(rèn)該指針是什么什么出現(xiàn)問題的，進行第20幀數(shù)據(jù)的詳細(xì)查看。其中我們用p命令查看該類下面的對應(yīng)的和17幀this的關(guān)系，確認(rèn)gyro_在這個函數(shù)執(zhí)行的時候，地址是否正確。

從上面來看在此處函數(shù)執(zhí)行的時候，對應(yīng)的gyro的地址還沒有變成錯誤的0x1388。

從這里我們基本可以確認(rèn)到，函數(shù)從 第20幀對應(yīng)位置執(zhí)行之后再到17幀的函數(shù)的時候，執(zhí)行函數(shù)的地址發(fā)生了改變      然后開始進入校對代碼的環(huán)節(jié)。

這個時候校對不是看代碼執(zhí)行的具體情況，因為發(fā)生問題的部分已經(jīng)是被修改了指針地址。所以我們需要從全局去看這個實體類被進行實體化和釋放操作的地方。

最終找到了一個出現(xiàn)線程調(diào)用先后順序?qū)е伦兞繘]有準(zhǔn)備好，出現(xiàn)的死機情況。

示例二：另一個指針問題

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

這個coredump文件在使用bt命令之后發(fā)現(xiàn) 此處的堆棧信息看上去都很正常，無法顯示出代碼在哪里了出現(xiàn)了問題。

這個時候我們就要考慮多線程時候，堆棧信息不一定直接捕獲到對應(yīng)線程，我們需要打開所有線程里面的堆棧信息。

thread apply all bt

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

thread apply all command //所有線程都執(zhí)行命令
對應(yīng)打印出所有線程的堆棧信息之后，我們就進行一點點查看，但是如果你的代碼定義了 信號處理函數(shù)，例如我使用了 handle_exit進行處理，然后我就在所有線程堆棧信息里面去搜索對應(yīng)最后面信號處理的函數(shù)，再往回查看程序執(zhí)行的過程。

此時我們發(fā)現(xiàn)led一個實體化類的的初始地址出現(xiàn)了問題，最后校驗代碼，發(fā)現(xiàn)了這個bug。

示例三：內(nèi)存溢出

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

此時發(fā)現(xiàn)當(dāng)前堆棧信息也無法進行定位到問題。

然后我們使用了thread apply all bt但是第一遍我們沒有看到對應(yīng)的hand_exit函數(shù)

然后我們使用 info locals查看一下保存的本地變量的信息

info f addr打印通過addr指定幀的信息。info args打印函數(shù)變量的值。

info locals打印本地變量的信息。

info catch打印出當(dāng)前的函數(shù)中的異常處理信息。

本地變量也沒有一些明顯表示出指針錯誤、數(shù)據(jù)越界的一些顯示。

所以 我們又使用 p指令打印幀信息里面保存的變量信息。

通過打印這些我們認(rèn)為出錯率比較高的變量信息，可以輔助我們進行判斷。不過本次打印也沒辦法確認(rèn)到問題位置。

然后我們重新看全部線程的堆棧信息。最終看到了一個異常的參數(shù)，這個值很大，有些異常。

緊接著我們進行查看對應(yīng)的源碼位置，因為是C 的庫，所以我們直接看編譯位置的代碼。

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

打開對應(yīng)的代碼位置之后發(fā)現(xiàn)**__n**參數(shù) 是進行分配空間的數(shù)量的參數(shù)。

再次查看執(zhí)行前后的 stl_vector.h:343

而現(xiàn)在傳入的__n大約是大于億的單位值，而代碼實際工作的位置是不需要這么大的空間分配的。所以確認(rèn)是此處有問題，對照代碼執(zhí)行的位置以及對應(yīng)變量的全局使用情況，最后基本定性為隊列在多線程使用中，鎖沒有使用好，導(dǎo)致多個線程在極端情況下，輸出和輸入操作會對同一個區(qū)域進行，導(dǎo)致了此次代碼死機。

結(jié)語

這就是我分享的項目中分析coredump文件的情況，如果大家有更好的想法和需求，也歡迎大家加我好友交流分享哈。

此外除了我文中使用的這些命令，大家也可以輔助gbd調(diào)試的更多命令來檢查我們coredump文件。例如查看匯編代碼等等。網(wǎng)上關(guān)于gdb調(diào)試命令的文章還是有很多，大家也可以輔助看其他文章命令使用。

作者：良知猶存，白天努力工作，晚上原創(chuàng)公號號主。公眾號內(nèi)容除了技術(shù)還有些人生感悟，一個認(rèn)真輸出內(nèi)容的職場老司機，也是一個技術(shù)之外豐富生活的人，攝影、音樂 and 籃球。關(guān)注我，與我一起同行。

???????????????? END ????????????????