低级错误案例集.doc

TOP1资源泄漏 资源泄漏(包括内存泄漏)是代码Review中最常见的错误之一,申请的每个资源必须明确由谁负责释放,何时释放,在何处释放;在异常/错误/返回处理中,保持清醒的头脑,清理战场。此处的资源还包括信号量、定时器、文件句柄等系统资源。【问题描述】 宏里面有return语句导致内存泄漏案例一。【问题分析】1)错误代码:/*定义宏MODEL_ASSERT_RETFAIL*/#defineMODEL_ASSERT_RETFAIL(X){if(X不合法)return;}….//dosomethingMDSTrafficMsg*pMsg=VOS_AllocMsg(PID_MD,usLength);if(NULL_PTR==pMsg){return;}MDSDataListenerMgr*pDataListener=MDSDataInitalListenerMgr();MODEL_ASSERT_RETFAIL(pDataListener);2)分析: 使用宏MODEL_ASSERT_RETFAIL检查pDataListener是否合法,如果不合法,则直接返回,一旦返回,将导致前面通过指针pMsg申请到的消息包资源泄漏。【纠正方法】在宏MODEL_ASSERT_RETFAIL分支判断return前加上VOS_FreeMsg(PID_MD,pMsg):该方法代码不够清晰,当用户看宏定义时,对VOS_FreeMsg(PID_MD,pMsg)不清楚还要跳回来看前面的代码。设定该宏有返回值(指针不为空返回VOS_True,否则为VOS_False),将宏的return语句写在宏使用后(判断指针pDataListener合法性),若宏返回VOS_False释放pMsg并返回主调函数:该方法在遇到只判断一个指针的合法性时,浪费代码行、降低代码飞检效率且可能存在宏描述歧义等问题,简单的判断建议不使用宏。【经验教训】在XX版本的一个新模块的开发中,在TR5之前进行大话务量测试验证时,发现系统内存资源不足,当时TR5在即,这个问题影响到TR5过点,经过协调多个技术专家封闭攻关,花了三天时间终于发现问题所在,人力成本高达3000,对于内存使用,要确保释放闭环,所有异常退出点都需要释放内存。【问题描述】 宏里面有return语句导致内存泄漏案例二。【问题分析】1)错误代码:头文件中的宏定义如下:/#defineNODE_RETURN_ERROR(p){if(NULL==p)\VOS_RECORD_ERROR(p);\returnNULL;\}文件中有个函数有如下代码段:...//dosomethingpNode=(Node_Head_S*)malloc(sizeof(Node_Head_S));NODE_RETURN_ERROR(pNode);//第一次使用宏pBody=(Node_Body_S*)malloc(sizeof(Node_Body_S));NODE_RETURN_ERROR(pBody);//第二次使用宏...//dosomething2)分析: 当通过指针pBody申请内存,然后通过宏NODE_RETURN_ERROR来判断是否申请成功,如果申请失败,则在宏NODE_RETURN_ERROR里面就直接返回了,这样导致通过指针pNode申请的内存泄漏了。【纠正方法】 不使用宏,或将宏中的return语句写到宏调用后。【问题描述】 异常出口没有释放应该释放的内存案例一。【问题分析】1)错误代码://GetBuff函数的作用是什么动态内存pMsgDB_DEV=(PDBDevMsg)GetBuff(sizeof(DBDevMsg),__LINE__);if(NULL==pMsgDB_DEV){return;} //GetBuff函数的作用是什么动态内存pMsgDBApp_To_Logic=(LPDBSelfMsg)GetBuff(sizeof(DBSelfMsg),__LINE__);if(NULL==pMsgDBApp_To_Logic){return;}2)分析: 在第2个return处,pMsgDB_DEV指向的内存丢失。【纠正方法】 在第2个return处增加释放内存的操作。【经验教训】 函数中有动态申请内存,要在函数范围内检查所有return语句是否释放该return语句前所有动态申请的内存。【问题描述】 异常出口没有释放应该释放的内存案例二。【问题分析】1)错误代码:/*申请内存空间,存放解压缩后的逻辑文件*/pucExpandBuf=(UCHAR*)VOS_MemAlloc((ULONG)PID_PHY,BLOCK_MEM_PT,VOIPFPGA_FILE_LENGTH);if(PTR_NUL