【正文】 lse // delete item。}。 有的程序員認(rèn)為，后臺(tái)運(yùn)行的環(huán)境有大量?jī)?nèi)存，幾個(gè)字節(jié)的浪費(fèi)不會(huì)造成死機(jī)等重大事故。然而，長(zhǎng)時(shí)間累計(jì)起來，必然會(huì)造成資源緊張而出現(xiàn)故障。 實(shí)際上，這種思想是造成我們產(chǎn)品不穩(wěn)定的原因之一。我們的主機(jī)在網(wǎng)上能運(yùn)行幾個(gè)月幾年，大家對(duì)內(nèi)存的分配釋放較敏感，而我們的后臺(tái)產(chǎn)品往往只能正常運(yùn)行幾天。這個(gè)地方不注意也是原因之一吧?！尽俊菊? 文】 在進(jìn)行代碼審查過程中，造成內(nèi)存泄漏的代碼比較多。下面舉幾種常見的內(nèi)存泄漏錯(cuò)誤，供測(cè)試人員在代碼審查中參考： 1. 函數(shù)有多個(gè)出口時(shí)，沒有在每個(gè)出口處對(duì)動(dòng)態(tài)申請(qǐng)的內(nèi)存進(jìn)行釋放。一般在異常處理時(shí)容易出現(xiàn)這種錯(cuò)誤。下面的代碼段就是這樣的例子：..... pRecord = new char[pTableGetRecordLength()]。 assert(pRecord != NULL)。 if (pTableGoTop(FALSE) != DBIERR_NONE) return。 // 如果從這里返回，pRecord將得不到釋放 ..... pTableClose()。 delete[] pRecord。 } 2. 給指針賦值時(shí)，沒有檢查指針是否為空，如果指針不為空，那么指針原來指向的內(nèi)存將丟失。請(qǐng)看如下代碼段：.... struct FileInfo * pdbffile = new struct FileInfo。 pdbffilepfileinfo = new struct ffblk。 pdbffilesrame = srcRootPath。 pdbffiledesname = desRootPath。 pdbffileprev = NULL。 pfile = pdbffile。//賦值之前沒有檢查一下pfile是否為空，如果不為空，會(huì)造成pfile指向的內(nèi)存丟失。 dbf_start_needed = FALSE。 dbf_Finish = FALSE。 flag_begined = TRUE。 if(FALSE == Copy(TRUE)) { dbf_start_needed = TRUE。 WarnMsgOut(Error occurs while copying files in directory dbf,trying again.)。 } } 3. 連續(xù)二次內(nèi)存動(dòng)態(tài)分配，在第二次分配失敗時(shí)，忘記釋放第一次已經(jīng)申請(qǐng)到的內(nèi)存。 .... pMsgDB_DEV = (PDBDevMsg)GetBuff( sizeof( DBDevMsg ), __LINE__)。 if( pMsgDB_DEV == NULL ) return。 pMsgDBApp_To_Logic = (LPDBSelfMsg)GetBuff( sizeof(DBSelfMsg), __LINE__ )。 if( pMsgDBApp_To_Logic == NULL ) return。//此處返回造成pMsgDB_DEV指向的內(nèi)存丟失 .... ，導(dǎo)致程序未執(zhí)行任何操作而退出時(shí)，也可能沒有釋放應(yīng)釋放的內(nèi)存，這種情況一般是缺少應(yīng)有的else分支，或switch語句的default分支沒有應(yīng)有的處理。static void OncePowerCmdHandle( struct HT_Appmsg * msg ){ ... ... pPower_test_answer =(struct _oncepower_test_answer *)GetBuff(sizeof(struct _oncepower_test_answer),__LINE__)。 if( pPower_test_answer == NULL_PTR ) return。 ... ... if (TSS_State[testpsn].state == TEST_DEV_BUSY || TSS_State[testpsn].state == TEST_DEV_ERROR ) {... } else if (TSS_State[testpsn].state == TEST_DEV_IDLE ) {... } // 缺少 else 分支，可能造成 pPower_test_answer 得不到釋放}造成內(nèi)存泄漏的情況很多，以上是幾種典型的情況。雖然內(nèi)存泄露一般出現(xiàn)在異常情況下，畢竟給系統(tǒng)造成很大的隱患，使系統(tǒng)的健壯性降低。測(cè)試人員在作代碼審查時(shí)，對(duì)上述幾種情況要尤其注意。【】【正 文】在進(jìn)行SAR的PDU包發(fā)收的測(cè)試過程中要同時(shí)考慮幾個(gè)邊界值,即發(fā)送包大小范圍[0Nmax],SAR的PDU包接收的最大值Kmax,將SAR的PDU包接收的最大值設(shè)為2000(Kmax=2000B), MBUF的塊長(zhǎng)設(shè)為512(M = 512B),則發(fā)送包大小的正確分支的取值為下限0,上限Nmax=2000,然后在0與2000之間隨機(jī)取若干值,再考慮MBUF的塊長(zhǎng),但由于很偶然的機(jī)會(huì)選擇包長(zhǎng)2000,及Kmax=2000B,:MBUF塊長(zhǎng)512,但塊中實(shí)際存放數(shù)據(jù)的只有500(MBUF頭上有2個(gè)長(zhǎng)字,尾部有1個(gè)長(zhǎng)字共12B只用于塊控制),而發(fā)送的包長(zhǎng)正好是500的整數(shù)倍4,由于是整數(shù)倍,所以SAR(BT8230)從FREE鏈上摘成5個(gè)MBUF(原因從略),而SAR驅(qū)動(dòng)只知道有4個(gè)MBUF,這樣到上層用戶時(shí),只釋放4個(gè)MBUF,從而漏掉1個(gè)MBUF,經(jīng)過很短一段時(shí)間后,內(nèi)存即被耗盡.(此問題非常嚴(yán)重,因?yàn)樵趯?shí)際運(yùn)用中,是500的整數(shù)倍的PDU包的概率較小,但一旦出現(xiàn)就會(huì)發(fā)生一次內(nèi)存泄漏,這樣經(jīng)過若干天或若干月的運(yùn)行后會(huì)使系統(tǒng)崩潰)以前未發(fā)現(xiàn)此問題的原因是因?yàn)樵瓉硎褂玫木彌_塊長(zhǎng)為2048,減去12B的控制信息,忽略了2036,所以在選取上下限中的若干值時(shí),選取包的長(zhǎng)度是2036的倍數(shù)的概率就非常小,因而未發(fā)現(xiàn)該問題.由于測(cè)試中一般很難將取值范圍中的所有值覆蓋全,所以在選取上下限中的若干取值時(shí)要格外仔細(xì),考慮的方面盡可能全,象該例中正確分支的測(cè)試邊界為0,2000,512及其整數(shù)倍,500 及其整數(shù)倍,12 及其整數(shù)倍等值,它們是必測(cè)的邊界值,而非可測(cè)可不測(cè)的隨機(jī)選取的所謂若干選值.【】【正 文】( )中，在進(jìn)行消息鏈表Msg_Queue[ces]的拆鏈操作時(shí)，對(duì)于相應(yīng)的CCB只進(jìn)行了一次拆鏈操作，即只拆除了一個(gè)節(jié)點(diǎn)，如果出現(xiàn)該CCB對(duì)應(yīng)的消息節(jié)點(diǎn)不止一個(gè)的情況就會(huì)出現(xiàn)大量節(jié)點(diǎn)不能釋放的問題。if( Msg_Queue[ces].msghead != NULL_PTR )//message buffer notempty{ //get first message record pMsgRecord = Msg_Queue[ces].msghead。 //release buffermessages concerning with ccb_no for( index = 0。 index MSGBUFFERNUM。 index++ ) { //這里要對(duì)pMsgRecord的值進(jìn)行判斷 if( (pMsgRecord != NULL_PTR) amp。amp。 pMsgRecordCCB_no == ccb_no ) { //free the message buffer if( pMsgRecord == Msg_Queue[ces].msghead )//head Msg_Queue[ces].msghead = pMsgRecordpnext。 else if( pMsgRecord == Msg_Queue[ces].msgtail )//tail { Msg_Queue[ces].msgtail = pPrevMsgRecord。 Msg_Queue[ces].msgtailpnext = NULL_PTR。 } else//not head and tail { pPrevMsgRecordpnext = pMsgRecordpnext。 } //put buffer back to buffer pool if( == 0 ) { = = pMsgRecord。 pMsgRecordpnext = NULL_PTR。//這里將 pMsgRecordpnext置為空 ++。 } else { pnext = pMsgRecord。 pMsgRecordpnext = NULL_PTR。//這里將 pMsgRecordpnext置為空 = pMsgRecord。 ++。 } } else if( pMsgRecord == NULL_PTR ) break。//end of if //get next message record pPrevMsgRecord = pMsgRecord。 pMsgRecord = pMsgRecordpnext。//這時(shí)pMsgRecord為 NULL_PTR將跳出for循環(huán)語句 }//end of for}//end of if這里在拆除一個(gè)節(jié)點(diǎn)后導(dǎo)致pMsgRecord為NULL_PTR，再進(jìn)行判斷時(shí)將會(huì)跳出循環(huán)，這樣將不能保證所有與同一個(gè)CCB有關(guān)的節(jié)點(diǎn)均被拆除，這時(shí)如果與同一個(gè)CCB對(duì)應(yīng)的消息節(jié)點(diǎn)不止一個(gè)則這些消息節(jié)點(diǎn)均無法釋放，造成可用的節(jié)點(diǎn)數(shù)不斷減少，直接影響系統(tǒng)的建鏈過程，給系統(tǒng)的穩(wěn)定帶來隱患。后與開發(fā)人員聯(lián)系，根據(jù)這段算法編寫小程序驗(yàn)證了該問題，并提出了相應(yīng)的解決方案，消除了該隱患。【】【正 文】 建立一個(gè)呼叫，并保持通話。在AM控存監(jiān)控操作界面中觀察通話建立在哪一塊FBI板上。 將有通話的FBI板拔出，觀察通話情況，此時(shí)話音中斷，但信令仍然保持。觀察AM控存監(jiān)控操作界面和E3M板2K網(wǎng)界面，發(fā)現(xiàn)AM側(cè)因?yàn)闄z測(cè)到光纖已斷，將通話在CTN、E3M板上占用的時(shí)隙置為空閑，即在AM控存監(jiān)控操作界面和E3M板2K網(wǎng)界面觀察不到時(shí)隙占用情況。 分別在30秒、1分鐘、3分鐘時(shí)將拔出的FBI板插回原槽位，發(fā)現(xiàn)每次插回FBI板后話音立即恢復(fù)。 觀察BAM上的打印消息，發(fā)現(xiàn)打印的各模塊占用CTN板大HW上DM時(shí)隙的空閑個(gè)數(shù)比較混亂。打印消息如下圖所示： 其中： 1） 由于模塊4各占用CTN板上兩條大HW，每個(gè)DM時(shí)隙個(gè)數(shù)為256（即由兩條大HW的兩個(gè)DM組成，由于與OPT相聯(lián)的大HW上有兩個(gè)保留時(shí)隙，因此此DM上空閑時(shí)隙個(gè)數(shù)為：254。 2） 由于E3M板只與一條大HW相聯(lián)，故每個(gè)DM上空閑的時(shí)隙個(gè)數(shù)為：128。 本現(xiàn)象對(duì)應(yīng)2個(gè)問題：idle_count打印混亂，BM釋放故障光路的時(shí)隙和對(duì)應(yīng)的CCB、無線信道等資源。 idle_count打印混亂是由于函數(shù)restore_one_hw中的一些處理不當(dāng)造成的，以前被當(dāng)作B型機(jī)的歷史遺留問題沒有重視；B2模塊有2條光路，如果斷掉其中一條，模塊狀態(tài)不會(huì)改變，原B型機(jī)程序?qū)Υ瞬蛔魅魏翁幚?，但?yīng)該增加這個(gè)功能，以免光路故障導(dǎo)致資源吊死。 解決方法： 問題一： 將函數(shù)restore_one_hw中原代碼作如下改動(dòng)： mod_dm[mod][i]. = idle_dm_head + 125。 ( idle_dm_head == 384 ) ? mod_dm[mod][i].idle_cou