前几天东政同学反馈说Linode服务器快卡死了，今天有时间排查了一下具体原因，最终原因稍微有点悲壮：file_get_contents没有设置超时时间，加上我用的php5.2关于curl的代码有个bug，于是导致PHP进程进入死循环。

今天下午又发现系统负载很高，于是上去看了一下，发现一大坨PHP进程没有退出，占用了很多CPU，如图：

问题进程：

后面运行的脚本是我的RSS定时更新任务，看来PHP代码什么地方有问题，于是strace -p 14043看了一下：

select(5, [4], [4], [], {15, 0}) = 1 (out [4], left {14, 999996})poll([{fd=4, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout)clock_gettime(CLOCK_MONOTONIC, {4582888, 760370017}) = 0clock_gettime(CLOCK_MONOTONIC, {4582888, 760468615}) = 0clock_gettime(CLOCK_MONOTONIC, {4582888, 760565053}) = 0select(5, [4], [4], [], {15, 0}) = 1 (out [4], left {14, 999997})

在４号fd上面死循环了，于是看看FD是什么：ll /proc/14043/fd

lrwx—— 1 wuhaiwen wuhaiwen 64 7月 21 11:00 4 -> socket:[53176380]

再看了一下原来是在请求CSDN的一个网页的时候死循环了，但不知道什么地方请求的，想到GDB一下php进程看看，bt显示：

(gdb) bt
#0 0x00007f6721f8f013 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1 0×0000000000481952 in php_curl_stream_read (stream=0×2280650,
buf=0x22ea5d0 “2Fmit，确实是一个bug, 其实curl_multi_fdset 的文档开头写了的：

复制代码 代码如下:
This function extracts file descriptor information from a given multi_handle. libcurl returns its fd_set sets. The application can use these to select() on, but be sure to FD_ZERO them before calling this function as curl_multi_fdset(3) only adds its own descriptors,

好吧，最后用GDB验证一下，我在上面的do下面，curl_multi_fdset调用之前，手动将fd清空，看看能否退出循环：

(gdb) print FD_ZERO(&curlstream->readfds)
No symbol “FD_ZERO” in current context.

FD_ZERO竟然没有，不管了，其本来是个宏定义，展开就行：#define FD_ZERO(p) bzero((char *)(p), sizeof(*(p)))

直接用call修改curl_muti_fdset的三个参数数组如下：

复制代码 代码如下:
(gdb) call bzero((char *)(&curlstream->readfds), sizeof(*(&curlstream->readfds)))
$5 = 17055392
(gdb) call bzero((char *)(&curlstream->writefds),sizeof(*(&curlstream->writefds)))
$6 = 17055520
(gdb) call bzero((char *)(&curlstream->excfds), sizeof(*(&curlstream->excfds)))
$7 = 17055648

然后GDB单步执行，如期的由于curlstream->pending变为0，从而退出了循环，回到php_stream_fill_read_buffer的大函数了

到此基本结束。有问题的PHP版本应该是5.2. 具体没有细看，读者可以参考下上面的这个提交改动或者直接看自己的版本代码是否有问题。