一个有趣的死循环问题

发表于 | |

问题引出

最近在工作过程中，遇到一个很有意思的bug，问题出现概率很小，很难复现，但是特别严重，直接导致用户无法使用App，属于不可容忍的问题，因此必须解决。问题出现在Android-App跑压测的过程中，我们提供的第三方库会突然停止工作，但是App的UI还是能正常的运转，于是我以我的职业敏感性当即做出判断（害羞 <逃），导致这个bug是因为我们提供的动态库中的消息线程被堵塞了，从而导致整个库无法工作。

通常情况下，线程被堵塞住，有下面几个原因：

  • 执行耗时任务（如网络IO或者文件IO等，导致整个线程卡死）
  • 死锁（消息线程拿着A锁，等待B锁，数据处理线程拿着B锁，等待A锁，相互等待，导致卡死）
  • 死循环（程序卡在一个循环，CPU狂转，无法跳出）

问题定位

首先第一个思路，就是在App出现卡主问题后，导出所有线程的调用堆栈，查看我们自己的库线程，看哪个线程哪个函数调用存在问题，取线程堆栈，通常有两个方法：

  • 在Android端，程序ANR后，系统会保留该进程的所有线程堆栈的traces文件。但是有个前提，只有主线程（UI线程）卡主的时候，系统才会生成这个文件，其他子线程或者库线程卡主是不会生成traces文件的。

  • 出现问题后，让App强制crash，生成crash线程堆栈。我们尝试让UI线程强制crash后，却只生成了UI线程的调用栈，没有我们库线程的信息。

抓调用栈的思路否定之后，我们决定先进一步缩小问题范围，出现卡主问题后，我们对Android手机执行了如下命令，找出我们App所有线程的运行状况。

1
adb shell top -m 20 -t

巧合地发现每次采样数据中，CPU使用率最高都是我们App进程中的同一个线程，正是我们动态库的消息线程，而该线程的使用率竟然比图像绘制线程占比还要高了几倍，很明显的异常，因此几乎可以断定是该线程导致的卡死问题，同时也可以排除死锁的可能性，因为死锁会让线程wait住，不会过多的占用CPU，同时由于我们的AppIO操作很少，也就排除了文件IO和网络IO，基本可以确认是死循环导致。

那么这个线程到底是在哪个位置卡死呢？这时候最笨的方法，效果最明显，【二分加Log法】，加log的位置以代码行数进行二分切隔，如果第N行日志没有输出，那么肯定说明问题代码在第N-1~N行之间，于是乎最终定位到了这一段神奇的死循环代码问题。

1
2
3
4
5
6
7
8
void TransAngleTo360(double& dAngle)
{
    while (dAngle < 0)
        dAngle += 360;
    
    while (dAngle > 360)
        dAngle -= 360;
}

这段代码，通过两个while循环将输入角度归化到0~360度之间，问题就出在这个输入值这里。通过复现的日志发现，代码走到了异常分支，对某个静态数组 double arrAngele[8]，执行了取下标-1的操作，arrAngele[-1]，产生了一个未定义的极大值，我们都知道8字节的double的取值范围是：

负值取值范围为 -1.79769313486231570E+308 到 -4.94065645841246544E-324；
正值取值范围为 4.94065645841246544E-324 到 1.79769313486231570E+308。

如果将1.79e+308这个数传给TransAngleTo360函数，那么函数需要执行5e+305次循环才能结束，假设我们的计算机每秒能执行10亿次机器指令，那执行完这个循环的时间，大约是1e+207秒。。。。

问题解决

对于函数输入参数，进行超大或超小值的范围控制，很明显这个方法只是暂时的补丁，且是在你知道入参大小的前提下，做的限制，如果不确定入参范围，很可能会出问题。

那么更好的做法其实是这样的，先看整数部分有多少个360，记为cnt，然后用原有角度减去cnt*360即可，为负数的时候对应处理下就行。

1
2
3
4
5
6
7
8
void TransAngleTo360(double& dAngle)
{
    int cnt = dAngle/360;
    if (time >= 0)
        dAngle = dAngle - cnt*360;
    else
        dAngle = dAngle - (cnt - 1)*360;
}