【文章內(nèi)容簡介】 ta ( DWORD *pdwWritePoint ) { BYTE bSlotID。 DWORD dwCCID, dwPeerCCID。 WORD wHdlcPort, wAtmPort, wIci 。 WORD wCount。 ．．． [wCount].bSlotID = bSlotID。 [wCount].wHdlcPort = wHdlcPort。 [wCount].wHdlcDlci = gFrPVCEP[bSlotID ][ gFrPVCC[bSlotID][dwCCID].dwLoPVCEP ].dwDLCI。 [wCount].wOldAtmPort = wAtmPort。 [wCount].wAtmDlci = gFrPVCEP[ bSlotID ][ gFrPVCC[bSlotID][dwCCID].dwHiPVCEP ].dwDLCI。 [wCount].dwMapMode = gFrPVCC[bSlotID][dwCCID].dwMapMode。 ．．． } DWORD RestoreFrNetExtIWFData ( WORD wSlotID, BYTE *pReadPoint ) { WORD wCount, wTotalNetIWF。 BYTE bSlotID, bHdlcDlciType, bAtmDlciType。 WORD wOldAtmPort, wAtmDlci, wHdlcPort, wHdlcDlci。 DWORD dwMapMode, dwCIR, dwBe。 DWORD dwCCID, dwResult, dwAtmPort。 wTotalNetIWF = 。 ．．． } DWORD RestoreFrHdlcIntIWFData ( WORD wSlotID, BYTE *pReadPoint ) { WORD wCount, wTotalHdlcIWF。 DWORD dwCCID, dwPeerCCID, dwAtmPort, dwPeerAtmPort。 DWORD dwResult。 BYTE bSlotID, bPeerSlotID。 WORD wHdlcPort, wOldAtmPort, wCIR。 WORD wPeerHdlcPort, wPeerOldAtmPort。 ．．． } 其中涉及 DLCI值的變量都為 WORD（即無符號短整型）類型，在程序的處理時，出現(xiàn) WORD和 DWORD（無符號長整型）類型在一句中同時存在的情況，至此可以判斷問題出在這里。由于 DLCI值在不同類型時的取值范圍不同，前三種類型的取值范圍為 16~991，第四種取值范圍為 2048~126975，第五種取值范圍為 131072~4194303，所以當(dāng)采用前三種 DLCI類型時，采用 WORD類型最大值為 65535，已經(jīng)完全夠用了；而對于第四種類型時，其取值在超過 65535時，獲取 DLCI值的函數(shù) _GetFrDlci（）采用 DWORD類型，而負(fù)責(zé)保存和恢復(fù)的兩個函數(shù) SaveFrNetExtIWFData（）和 RestoreFrNetExtIWFData（），都把 DLCI的值當(dāng)作 WORD類型進(jìn)行處理，因此導(dǎo)致 DLCI取值越界，于是程序把原本為長整型的DLCI強(qiáng)制轉(zhuǎn)換成整型，從而導(dǎo)致 DLCI值在恢復(fù)時，比原數(shù)據(jù)小 65536。而在程序運行過程中，這些數(shù)據(jù)保存在 DRAM中，程序運行直接從 DRAM中獲取數(shù)據(jù)，程序不會出錯；當(dāng) FRI板復(fù)位或插拔后，需要從 FLASH中讀取數(shù)據(jù)，此時恢復(fù)函數(shù)的錯誤就表現(xiàn)出來。 另一個問題是為什么 23/4類型的 DLCI數(shù)據(jù)不能恢復(fù)？這是由于對于 23/4類型的 PVC，其 DLCI的取值范圍為： 131072~4194303，而程序強(qiáng)制轉(zhuǎn)換并恢復(fù)的數(shù)據(jù)最大只能是 65535，所以這條 PVC不能恢復(fù)。 至此， DLCI數(shù)據(jù)恢復(fù)出錯的原因完全找到，解決的方 法是將 DLCI的類型改為 DWORD類型。從這個案例可以看出，在程序開發(fā)中一個很低級的錯誤，將在實際工作中造成很嚴(yán)重的后果。 正確使用邏輯與 amp。amp。、屏蔽 amp。操作符 【案例 】 【案例描述】：由于 C語言中位與比求模效率高，因而系統(tǒng)設(shè)計時，對于模 128的地方都改為與 127，系統(tǒng)定義的宏為 define MOD128 127和 define W_MOD 127(定義的宏的名字易引起誤解 )，但實際程序中還是采取求模，從而引起發(fā)送窗口欲重發(fā)的和實際重發(fā)的不一致，最終導(dǎo)致鏈路復(fù)位此類嚴(yán)重問題，曾在定位此 問題時花了不少時間。 【處理過程】：處理過程如下： define MOD128 127 //隊列長 128，當(dāng)隊頭到 128時，上其返回。 define W_MOD 127 //發(fā)送窗口隊列，意義同上。 在函數(shù) L2_TO_L1()中，有如下語句： linkstate_ptr = (head + 1) % W_MOD 。 這里當(dāng) head=126時， = 0，這將造成發(fā)送窗口指針和隊列窗口 指針錯位，造成鏈路復(fù)位 。 另外，在重發(fā)函數(shù) void INVOKE_RETRANSMISSION(_US logic_link,_US n_r)中，有如下語句： retran_num = (LinkState[logic_link].Vs + MOD128 (_UC)n_r) % MOD128 。 w_head = (LinkState[logic_link]. + W_MOD retran_num) % W_MOD 。 第一個語句求欲重發(fā) 的消息包個數(shù)，第二個語句求重發(fā)的起始位置，當(dāng) Vs小于n_r時，將造成實際重發(fā)數(shù)小于欲重發(fā)數(shù)，同時造成實際起始重發(fā)位置和欲重發(fā)起始位置錯開，從而引起鏈路復(fù)位。上面三個語句應(yīng)該做如下改動： linkstate_ptr = (head + 1) amp。 W_MOD 。 retran_num = (LinkState[logic_link].Vs + MOD128 + 1 (_UC)n_r) amp。 MOD128 。 w_head = (LinkState[logic_link]. + W_MOD + 1 retran_num) amp。 W_MOD 。 【結(jié) 論】：由于鏈路通信對系統(tǒng)效率要求很高，算法采用效率最高的，但位與（ amp。）和求模（ %）這小小的區(qū)別，造成的竟是鏈路復(fù)位這種嚴(yán)重的錯誤。 【思考與啟示】：對這類問題，大家在閱讀代碼或代碼審查時一定要注意，仔細(xì)一點往往能發(fā)現(xiàn)問題，但在測試中來定位這種問題，花費的時間往往更長。 注意數(shù)據(jù)類型的匹配 【案例 】 【案例描述】 下面通過測試中的一個例子來說 明這個問題：命令 DSP N7C是用來顯示 NO7電路狀態(tài)的，其參數(shù)設(shè)備類型 DID支持 TUP和 ISUP，參數(shù)信道號 BSN支持多值輸入（最多支持 32路查詢），正常情況下該命令沒有問題。但試了非正常情況下，問題就出來了。 首先試 BSN參數(shù)越界情況，即參數(shù) BSN超過 32路查詢，選了幾個數(shù)據(jù)段，問題就出來了。對于 0amp。amp。300和 0amp。amp。256，該命令返回結(jié)果不一致，對前者認(rèn)為參數(shù)越界，對后者返回執(zhí)行成功。 對于參數(shù) DID，選定一種設(shè)備類型（ TUP或 ISUP），讓參數(shù) BSN所包含的32路電路跨越 TUP和 ISUP， 兩次結(jié)果是不一致的。 【處理過程】 反饋到開發(fā)人員那里，第一個問題是 BAM的問題，第二個問題是 SM的問題。 【結(jié) 論】 為數(shù)據(jù)超出范圍溢出造成， int值賦值給 BYTE，造成數(shù)據(jù)丟失。 問題的產(chǎn)生是因為查詢的第一個信道是 TUP電路，但是卻按 ISUP電路查詢。 ISUP的維護(hù)處理函數(shù)判斷第一個信道不是 ISUP信道，認(rèn)為整個的 PCM不是ISUP類型的 PCM，返回全部的電路狀態(tài)為未安裝。消息處理不合理。 TUP也會產(chǎn)生如此錯誤。 【思考與啟示】 我們的 MML命令并不是無懈可擊的，許多表面上的小問題， 往往隱藏著代碼的缺陷和錯誤。 【案例 】 【正 文】 當(dāng)我們使用 PCLINT檢查代碼時，會發(fā)現(xiàn)大量的數(shù)據(jù)類型不匹配的告警，大部分情況下，這種代碼上存在的問題并不會引起程序功能實現(xiàn)上的錯誤，但有些情況下，也許會產(chǎn)生嚴(yán)重的問題： 一、不同數(shù)據(jù)類型變量之間賦值引起的問題，實際上，該類問題也可以分為幾種情況： 直接賦值，比如，把一個 WORD型變量賦給一個 INT型變量，如果WORD型變量大于 32767， INT型變量得到的就是一個負(fù)值了。 【例一】一次測試過程中發(fā) 現(xiàn)， SDH送的告警在 BAM調(diào)試窗口打印出紅色提示： File(XXX),Line(XXX):Invalid alarm id ,from: 7, AlarmId: 65463 經(jīng)過檢查數(shù)據(jù)發(fā)現(xiàn)，并沒有 ID為 65463的告警，分析上報的數(shù)據(jù)幀，發(fā)現(xiàn)上報的告警 ID為 B7，原來代碼中有一處強(qiáng)制類型轉(zhuǎn)換： = (WORD)RecvBuffer[iTmpLen + 5]。 char型強(qiáng)制轉(zhuǎn)換成 WORD型。 B7就變成了 FFB7，十進(jìn)制就是 65463。由于 char是有符號型， B7的第 8位為 1，所以轉(zhuǎn)換后為 FFB7，而不是代碼作者希望的 00B7，如果第 8位是 0，或該變量是 BYTE型，轉(zhuǎn)換就不會有問題了。 函數(shù)形參和實參不一致，實際上和第一種情況本質(zhì)上是一樣的，只是表現(xiàn)的形式不太一樣，這種情況也是代碼中經(jīng)常出現(xiàn)的問題 ,下面例子是測試中曾經(jīng)發(fā)現(xiàn)的一個小問題： 【例二】在 file01中的 INT DebugMsgProc(char byMsg0, char byMsg1)函數(shù)，兩個形參都是 char型，而實際傳入的參數(shù)都是 BYTE型，結(jié)果函數(shù)中的如下語句： PrintfE(PID_RED, %d ticks time out!,byMsg1)。 在 byMsg1大于 127時，輸出錯誤的結(jié)果。 二、不同數(shù)據(jù)類型之間的比較操作 在循環(huán)終止條件的判斷中，不同類型變量的比較操作是容易造成死循環(huán)錯誤的地方，同時也是開發(fā)人員容易忽視的地方，值得測試人員多加留意。下面兩個例子是該類錯誤的兩種典型情況： 【例三】 file02文件中某函數(shù)中如下代碼，可能造成死循環(huán)： ...... int i。 WORD *pCheck =(WORD*)p。 WORD wCheckSum=*pCheck。 pCheck++。 for(i=1。idwLen/2。i++) { wCheckSum^=(*pCheck)。 pCheck++。 } //binlen had already word alignment return (wCheckSum)。 ...... 該段代碼是在 DOS環(huán)境下用 BC編譯的，由于循環(huán)變量 i是 int型（ 2個字節(jié)），而 dwLen是 DWORD型（ 4個字節(jié)），如果 dwLen大于 65536，那么該函 數(shù)就是死循環(huán)了。 上面的例子是不同類型變量之間直接比較操作，還有一種情況是函數(shù)的返回值與另一不同類型的變量比較，見下面例子： 【例四】 ， while( ftell(fp) Part[3]) {..... } ftell返回 long型，而 Part是 DWORD型，有符號變量和無符號變量的比較，可能造成死循環(huán)。 類似的例子還有很多，類型不匹配的問題還有許多種情況，都是代碼中的隱患，有時會造成嚴(yán)重的 后果，需要引起足夠的重視。對于該類問題，我們可以利用 PCLINT工具對代碼進(jìn)行細(xì)致的檢查。 用于控制條件轉(zhuǎn)移的表達(dá)式及取值范圍是否書寫正確 【案例 】 【案例描述】： 在測試主機(jī) MPU板倒換功能時，如果 MPU備份充分，倒換前后對處于激活狀態(tài)的電路應(yīng)無影響，即不影響通話。但近期測試發(fā)現(xiàn)，如果兩局通過 DT板進(jìn)行一號對接， MPU備份倒換卻發(fā)生斷話。具體現(xiàn)象為：如果 DT板的第 1個 PCM系統(tǒng)電路為故障，則 MPU倒換時復(fù)位該 DT板，如果 DT板的第 2個 PCM系統(tǒng)電路為故障，則 MPU倒換時復(fù)位下一塊 DT。 【處理過程】： 據(jù)查， MPU倒換時會自動復(fù)位處于“故障”態(tài)的電路，但由于計算錯誤（多加了 32），錯復(fù)位了下一個 PCM系統(tǒng) 32路電路。 【結(jié) 論】： 如此嚴(yán)重問題為什么到今天才發(fā)現(xiàn)？因為我們在實驗室中一般采用同一單板的 2個 PCM系統(tǒng)自環(huán)進(jìn)行測試，則不會在某單板上有故障和空閑電路共存，自環(huán)屏蔽了錯誤。 【思考與啟示】： 自環(huán)是在測試環(huán)境下常用的一種提高效率的