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