前言

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

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

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

對(duì)于此，高工的判斷要么是數(shù)組越界，要么是因?yàn)橐爸羔槍?dǎo)致該函數(shù)指針被意外修改。

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

最新評(píng)論