今天遇到一個問題,調(diào)試了一天.
大致描述一下,移植一個開源項目的代碼,原來在mips平臺上運行正常,后來到arm平臺的機器上運行,結(jié)果運行時出錯了.
一般的,這樣的問題,腦子里面第一下的反應(yīng)就是由于字節(jié)序問題造成的.
我起初也是這么想的.因為從出錯的現(xiàn)象來看,是某個字段不符合要求造成的出錯.于是沿著這個思路去找BUG.抓包來分析,看上去也是這樣的.但是,追蹤的過程中發(fā)現(xiàn),有多次收發(fā)報文的過程,這個字段,或者說擁有這個字段的結(jié)構(gòu)體在多處都有使用,改了一處,在別的地方其它字段又有報錯.
回頭看代碼,發(fā)現(xiàn)在最開始解析包頭的時候,已經(jīng)造成了緊跟著包頭的某個字段出現(xiàn)異常,于是,想到是不是在不同的平臺上,sizeof(某結(jié)構(gòu)體)的數(shù)值不一樣造成,要驗證這一點,給包頭結(jié)構(gòu)體的定義加上嚴(yán)格按照一個字節(jié)對齊的限制,重新運行程序,可以了.
最后再來稍微詳細(xì)一些看這個問題,假設(shè)包頭結(jié)構(gòu)體的定義是:
typedef unsigned short u16;
struct header
{
u16 a;
u16 b;
u16 c;
};
如果解析的時候,sizeof(struct header) != sizeof(u16) * 3,那么使用sizeof(struct header)解析接收到緩沖區(qū)的數(shù)據(jù)就會出現(xiàn)問題,因為它會對緊跟著的數(shù)據(jù)也造成影響.程序的異常正是源于此.在代碼的處理中,首先接收包頭,對包頭的數(shù)據(jù)進(jìn)行了字節(jié)序轉(zhuǎn)換,然后,又對緊挨著包頭的結(jié)構(gòu)體進(jìn)行了相同的字節(jié)序轉(zhuǎn)換,由于包頭結(jié)構(gòu)體的字節(jié)序轉(zhuǎn)換同時影響了緊挨著的結(jié)構(gòu)體中的數(shù)據(jù),所以這些數(shù)據(jù)實際上被進(jìn)行了兩次的字節(jié)序轉(zhuǎn)換,這才造成了這個問題"看上去"是字節(jié)序轉(zhuǎn)換不當(dāng)造成的"表面原因",如果跟著這個原因繼續(xù)跟蹤下去,以這個思路解決問題,治標(biāo)而不治本.
總結(jié):
1. 收發(fā)數(shù)據(jù)的結(jié)構(gòu)體定義需要嚴(yán)謹(jǐn)一些,如果不能確定如何對齊,最好自己定義一個對齊的標(biāo)準(zhǔn).
2. 經(jīng)驗有的時候也不見得就是好事,有時候會讓自己陷入思維定式的怪圈,比如在這個問題的處理上,由于問題在切換了硬件平臺的時候才出現(xiàn),正好又是兩個字節(jié)序不一樣的硬件平臺,所以經(jīng)驗將我的思路導(dǎo)向了字節(jié)序不正確這個方向上.