低级错误集答案.doc

TOP1 资源泄漏 资源泄漏（包括内存）是代码Review中最常见的错误之一，申请的每个资源必须明确由谁负责释放，何时释放，在何处释放；在异常/错误/返回处理中，保持清醒的头脑，清理战场。 案例1.1 【问题描述】 宏里面有return语句导致内存泄漏案例一。 【问题分析】 1) 错误代码： /*定义宏MODEL_ASSERT_RETFAIL*/ #define MODEL_ASSERT_RETFAIL (X) \ { \ if(X不合法) \ return; \ } ….//do something MDSTrafficMsg* 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版本的一个新模块的开发中，在发布之前进行大话务量测试验证时，发现系统内存资源不足，当时发布在即，经过协调多个技术专家封闭攻关，花了三天时间终于发现问题所在，人力成本高达3000元，对于内存使用，要确保释放闭环，所有异常退出点都需要释放内存。 案例1.2 【问题描述】 宏里面有return语句导致内存泄漏案例二。 【问题分析】 1) 错误代码： 头文件中的宏定义如下： #define NODE_RETURN_ERROR (p) \ {\ if (NULL == p) \ {\ VOS_RECORD_ERROR(p);\ return NULL;\ }\ } 文件中有个函数有如下代码段： ...//do something pNode = (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); //第二次使用宏 ...//do something 2）分析： 当通过指针pBody申请内存，然后通过宏NODE_RETURN_ERROR来判断是否申请成功，如果申请失败，则在宏NODE_RETURN_ERROR里面就直接返回了，这样导致通过指针pNode申请的内存泄漏了。 【纠正方法】 不使用宏，或将宏中的return语句写到宏调用后。 案例1.3 【问题描述】 异常出口没有释放应该释放的内存案例一。 【问题分析】 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语句前所有动态申请的内存。