前言

項目代碼中經(jīng)常出現(xiàn)莫名其妙的Bus error問題，并且代碼中增加很多try catch 后依然不能將錯誤捕獲，一旦Bus erro出現(xiàn)，進(jìn)程直接崩潰掉。類似如下這種:

經(jīng)查詢google，出現(xiàn)該問題一般是因為地址未對齊引起的，也就是程序試圖訪問一個不是地址的值。從而導(dǎo)致該錯誤。后經(jīng)公司高工通過gdb運行代碼后查看匯編發(fā)現(xiàn)，寄存器中確實存儲了一個非地址的值(50位， 64位機器的實際內(nèi)存地址應(yīng)該為48位，高位用于尋址)，導(dǎo)致在訪問時出現(xiàn)Bus-error。

更奇怪的是，該問題不會一直復(fù)現(xiàn)，而是經(jīng)常跑幾個小時，然后在調(diào)用函數(shù)指針的時候崩潰一次。提示UpdateDataPtr指向的一個空地址。

對于此，高工的判斷要么是數(shù)組越界，要么是因為野指針導(dǎo)致該函數(shù)指針被意外修改。

順著這個思路，一開始是通過內(nèi)存監(jiān)控，查看是誰修改了該內(nèi)存，但是并未守到結(jié)果。此時高工想通過分析內(nèi)存的方式看能不能找到一些線索。

*** 操作方法就是在該指針前后增加標(biāo)記變量，然后通過程序掛掉時候的core dump 查看那時刻的內(nèi)存結(jié)構(gòu)，從而嘗試分析問題***

最后發(fā)現(xiàn)代碼中的一個單例中定義了一個數(shù)組u_char crcbuf[64]; 在寫這個數(shù)據(jù)的時候發(fā)生越界，最終將該變量下的指針變量也覆蓋了

寫成我們接收到的里程計數(shù)據(jù)了，從此真相大白！

對于此，接著分析是如何導(dǎo)致該問題的呢？

看看報文就知道了，正常報文的數(shù)據(jù)部分出現(xiàn)了報頭一樣的情況，導(dǎo)致程序誤認(rèn)為讀取的數(shù)據(jù)大小為176個字節(jié)，那么在計算crcbuf的時候也會嘗試放入176個字節(jié)，最終產(chǎn)生數(shù)組越界，將函數(shù)指針覆蓋。

總結(jié)

1 該問題從出現(xiàn)到解決持續(xù)了好幾周，一直沒有好的方案。

2 遇到問題不能回避，應(yīng)該迎難而上，實在不行請教公司高工。

3 C++ 中無法對數(shù)組越界的問題進(jìn)行捕獲, 因此務(wù)必小心使用數(shù)組和指針

4 C++中內(nèi)存分析和gdb調(diào)試要及早掌握，對于分析復(fù)雜問題幫助很大

以上就是關(guān)于C++出現(xiàn)Bus error問題的排查與解決的詳細(xì)內(nèi)容，更多關(guān)于C++出現(xiàn)Bus error的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論