服务器程序常见bug总结

服务器程序常见bug总结

   最近整理了过去一年发生过的bug，包含跟其他项目组程序朋友交流的例子, 都是大家发生过的真实营运事故。
   游戏服务器程序，很多bug的原因都是共通的。抽象出了以下10点启示, 作为checklist, 写下来以后写程序review时自检：

1. 安全边界问题

     对于有界限的东西（数值，buffer空间，队列或一切对象容器），一定要考虑越界判断。
     启示：用snprint, strncpy等限制长度.  永远都要考虑超过边界的情况

               数值加法和乘法：考虑上限溢出; 

               减法：考虑负数; 除法，判断分母

2. 输入参数非法

    case1: 扣钱逻辑，减去一个负数，变成了加钱。  
    case2: int型大负数相加，负溢出变成大正数
    启示：test case要全覆盖输入参数范围, 处理各种可能的情况

3. 上下文改变错误

     共享变量/全局变量被外部改变，这似乎很常见，而且有时很隐蔽。在异步回调的情况下更常见。

     check A变量 
     call func_B()
     ....
     A变量被func_B改变了, 但继续信任A变量check的结果。

    启示：白盒复查代码时，注意检查调用后的变化。

               减少共享变量和全局变量的使用

               外部接口调用后，注意共享变量的更新和恢复

     启示：在最接近执行的地方，检查上下文变量。不信任调用者，如果效率不关键，多一遍冗余检查没有坏处

4. 执行中断

     动态脚本抛异常，或者引擎层面的EINTR中断信号，都有可能中断代码执行，需要考虑函数的重入性问题。
     启示：要检查一致性，有些逻辑不允许多次被执行（比如发奖励），需要有状态变量确保只执行1次（避免出刷bug）
     推广到异步环境（多线程，多进程，各种回调），事务的中断也有一个重入性问题，解决方法也只有一个：用一个唯一可辨认的状态变量，保证某些逻辑不会被多次执行（比如购物应用中，用唯一订单号来识别，状态改变是一次性的，当逻辑运行多次，也不会重复加物品，或者重复扣钱了）

5. 终止条件问题--死循环

     case: 异步环境中，RPC远程调用，调用成环，逻辑一直不结束。
     启示：while或递归的终止条件，逻辑全覆盖检查，避免死循环。较深层次的互相调用，要注意是否出现了递归，是否有可能死循环。

6. 关联数据操作的不一致

     例子：Employee对象有company变量， Company中有employee变量，

          如果操作改变其中一方，而另一方没有改变，则造成数据不一致。

      （数据库表可以指定constrain, 关联表删除, 但代码变量中需要程序员自己实现）

       双向引用的数据一致性问题，要特别注意。

       为什么要双向引用？为了查找效率，而避免遍历其中一方.
       这个问题本质是数据一致性问题，编程中遇到的很多bug也归结到这个问题，比如野指针，就是因为数据结构相互引用的操作不一致造成的。
       处理这个问题，个人经验是，他们的attach，detach操作尽可能在同一个模块，不要分散在多个地方随意修改，所有修改都集中在同一级接口做。

       同理适用于new, delete, malloc, free这些分配，释放，都集中在同一层的接口/模块文件中做，debug起来也容易；非常反感在一个地方new, 然后不知道哪个模块去delete, 很容易泄漏或者野指针, 无论如何，想办法传递这些指针，一直传到分配他所在的模块文件中释放，而且new和delete的接口代码要靠近，方便查找问题。

7. 涉及多玩家，防止笔误传错参数

     经典错误： foreach(uid in team) some_func(usernum, xxx)   

     经典错误：有usernum和target两个对象，调用函数搞混了。review时要仔细检查

8. 特殊分支忘了return

     异常判断等if分支忘了return。导致逻辑继续往下走。这属于笔误问题，测试期间未必能留意的到。

9. 异步返回没清变量

    对于异步操作，如果在返回时清变量，这时如果不能保证把变量清掉（比如期间玩家下线无法离线修改该变量），就会出刷。

    启示：对于已奖励标记，一定要保证各种情况下领奖后能正确记录。

10. 瞬爆容量上限

     case1:  网络待发送队列，因为瞬间大量请求，塞满抛异常，导致流程受影响。

     case2:  大量连接请求，listen的accept没有规定单次读事件的accept，用了while(true), 导致爆机
                在listen fd的读事件回调中, 通常会accept所有新的连接请求，如果用while(true)而不设一个上限，就有可能被攻击（想象一下客户端也用一个死循环来做connect)。
                一方面要限制单次接受的socket次数, 另外各个状态要有超时机制，踢掉不寻常的连接，以防被攻击占尽资源。

     case3: 异步情况下，要限制操作者连续频繁的操作。（比如在请求入口处增加最少时间间隔限制，避免玩家狂点，形成雪崩效应）
                （同时要考虑用户体验，不要让玩家死等，可以做一个提示跳转，或者等候的动画）

参考资料：
附上最近看的一篇文章
<Writing-reliable-online-game-services> 作者曾是魔兽争霸和星际争霸，battle.net的开发者，
里面讲的point也是游戏里经常遇到的可靠性问题。

http://www.codeofhonor.com/blog/wp-content/uploads/2012/04/Patrick-Wyatt-Writing-reliable-online-game-services.pdf