前言：

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

作者：良知猶存

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

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

情節(jié)介紹:

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

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

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

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

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

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

gdb executable_file coredump_file

示例一：指針初始化失敗

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

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

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

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

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

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

然后我們需要確認(rèn)該指針是什么什么出現(xiàn)問題的，進(jì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ā)生了改變      然后開始進(jìn)入校對代碼的環(huán)節(jié)。

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

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

示例二：另一個指針問題

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

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

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

thread apply all bt

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

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

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

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

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

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

然后我們使用了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)為出錯率比較高的變量信息，可以輔助我們進(jìn)行判斷。不過本次打印也沒辦法確認(rèn)到問題位置。

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

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

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

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

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

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

結(jié)語

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

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

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

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