低级错误案例集.doc

低级错误案例集内部公开 2017-2-13 第 1页,共 76 页 TOP1 资源泄漏资源泄漏( 包括内存泄漏) 是代码 Review 中最常见的错误之一, 申请的每个资源必须明确由谁负责释放,何时释放,在何处释放;在异常/ 错误/ 返回处理中,保持清醒的头脑,清理战场。此处的资源还包括信号量、定时器、文件句柄等系统资源。案例 【问题描述】宏里面有 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 申请到的消息包资源泄漏。低级错误案例集内部公开 2017-2-13 第 2页,共 76 页【纠正方法】在宏 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) 错误代码: 头文件中的宏定义如下: / #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)); 低级错误案例集内部公开 2017-2-13 第 3页,共 76 页 NODE_RETURN_ERROR (pBody); // 第二次使用宏...//do something 2) 分析: 当通过指针 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