前言：

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

作者：良知猶存

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

或者添加作者個(gè)人微信：become_me

情節(jié)介紹:

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

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

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

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

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

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

gdb executable_file coredump_file

示例一：指針初始化失敗

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

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

f  n
通過幀編號(hào)來選擇幀，幀編號(hào)可以通過 bt 命令來查看。

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

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

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

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

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

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

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

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

示例二：另一個(gè)指針問題

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

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

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

thread apply all bt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)語

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

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

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

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