php5.2的curl-bug 服务器被php进程卡死问题排查(php_curl.dll)

推荐整理分享php5.2的curl-bug 服务器被php进程卡死问题排查(php_curl.dll)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:php curl_multi_init,php curl_exec,php curl命令详解,php curl_init,php_curl.dll,php curl ua,php curl_multi_init,php curl_init,内容如对您有帮助，希望把文章链接给更多的朋友！

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

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

问题进程：

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

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

lrwx—— 1 wuhaiwen wuhaiwen 7月 : 4 -> socket:[]

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

(gdb) bt#0 0xff8f in __select_nocancel () at ../sysdeps/unix/syscall-template.S:#1 0× in php_curl_stream_read (stream=0×, buf=0xea5d0 “2Fwww.laruence.com%2Ftag%2F%e6%ad%a3%e5%%%+class%3D%tag-link-%+title%3D%+topics%+style%3D%font-size%3A+9.pt%3B%%3E%E6%AD%A3%E5%%%3C%2Fa%3E%3C%2Ftags%3E”"…, count=) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/ext/curl/streams.c:#2 0xf9 in php_stream_fill_read_buffer (stream=0×, size=) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/main/streams/streams.c:#3 0xc in _php_stream_read (stream=0×, buf=0xfd5 “f=' class='tag-link-′ title='3 topics' style='font-size: 9.pt;'>json</a>n<a href=' class='tag-link-′ title='2 topics' “…, size=) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/main/streams/streams.c:#4 0xc in _php_stream_copy_to_mem (src=0×, buf=0x7fffed, maxlen=<optimized out>, persistent=0)at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/main/streams/streams.c:#5 0xfdb in zif_file_get_contents (ht=<optimized out>, return_value=0xda0, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>)at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/ext/standard/file.c:#6 0xc2a in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffedc) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/Zend/zend_vm_execute.h:#7 0xcf in execute (op_array=0x1f) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/Zend/zend_vm_execute.h:·············# 0xd8e in main (argc=4, argv=0x7ffff) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/sapi/cli/php_cli.c:

看一下当前PHP执行的脚步是什么：

找到了问题代码位置，原来是一个file_get_contents($url)调用，没有设置超时时间，于是PHP卡死在网络请求了。于是用stream_context_create 设置超时时间搞定。

到这里 似乎问题解决了，但是，为什么没有设置超时时间就导致php进程占用CPU，系统负载那么高？按理说应该等待I/O才是呀？看上面CPU情况，完全是进入了死循环的节奏。

根据上面的bt堆栈，首先看倒数第二个函数的调用：

#1 0× in php_curl_stream_read (stream=0×, buf=0xea5d0 “2Fwww.laruence.com%2Ftag%2F%e6%ad%a3%e5%%%+class%3D%tag-link-%+title%3D%+topics%+style%3D%font-size%3A+9.pt%3B%%3E%E6%AD%A3%E5%%%3C%2Fa%3E%3C%2Ftags%3E”"…, count=) at /home/wuhaiwen/install/php-env/src/php/php-5.2.8/ext/curl/streams.c:

看一下代码，我用的事5.2.8版本的PHP，比较老。代码如下：

GDB进去发现，代码一直在里面的do-while里面循环了！心想curl_multi_fdset怎么不用先FD_ZERO 清空FD呢？一般做法都是会先清空的。

莫非是PHP的bug, 于是网上找了一下发现了这个Pierrick-Charron的commit，确实是一个bug, 其实curl_multi_fdset 的文档开头写了的：

好吧，最后用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单步执行，如期的由于curlstream->pending变为0，从而退出了循环，回到php_stream_fill_read_buffer的大函数了

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

PHP mysqli_free_result()与mysqli_fetch_array()函数详解 PHPmysqli_free_result()与mysqli_fetch_array()函数mysql_free_result()仅需要在考虑到返回很大的结果集时会占用多少内存时调用。在脚本结束后所有关联的内存都会被

php简单压缩css样式示例 本文实例讲述了php简单压缩css样式的方法。分享给大家供大家参考，具体如下：$css='';//找css目录$root=$_SERVER['DOCUMENT_ROOT'].'/css/';//directorywherethecsslives$files

php实现压缩合并js的方法【附demo源码下载】 本文实例讲述了php实现压缩合并js的方法。分享给大家供大家参考，具体如下：test.php文件如下：require_once('jsmin.php');$files=glob("js/*.js");$js="";foreach($filesas$