PHP stream未能及时清理现场导致Core的bug
同事发现一个在使用set_error_handler的时候, 能100%重现的core, 提炼后的重现代码如下(环境必须不能访问internet):
<?php function err_handler(){ exit; return true; } set_error_handler('err_handler'); $client = file_get_contents("http://www.laruence.com/ServiceNoWse.asmx?WSDL");
这段代码, 放在webServer中, 第一次访问不会有事, 第二第三次的时候就会出core.
gdb跟踪以后发现, core出在php_stream_display_wrapper_errors函数中, 对err_stack中的错误信息字符串做处理的时刻, core的堆栈如下:
#0 0x000000302af6ff20 in strlen () from /lib64/tls/libc.so.6 #1 0x0000002a989d97c1 in php_stream_display_wrapper_errors (wrapper=0x2a98e884a0, path=Variable "path" is not available. ) at /home/huixc/package/php-5.2.14/main/streams/streams.c:151 #2 0x0000002a989dca22 in _php_stream_open_wrapper_ex (path=0x76e7c8 "http://www.laruence.com/ServiceNoWse.asmx?WSDL", mode=0x2a98ae3087 "rb", options=8, opened_path=0x0, context=0x76e808) at /home/huixc/package/php-5.2.14/main/streams/streams.c:1893 #3 0x0000002a98966541 in zif_file_get_contents (ht=-1729541984, return_value=0x76e738, return_value_ptr=Variable "return_value_ptr" is not available. ) at /home/huixc/package/php-5.2.14/ext/standard/file.c:541 #4 0x0000002a98a2c05e in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffca30) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:200 #5 0x0000002a98a2b671 in execute (op_array=0x769890) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:92 #6 0x0000002a98a0c734 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/package/php-5.2.14/Zend/zend.c:1134 #7 0x0000002a989c965d in php_execute_script (primary_file=0x7fbfffef00) at /home/huixc/package/php-5.2.14/main/main.c:2036 #8 0x0000002a98a9bd36 in php_handler (r=0x8f1ba8) at /home/huixc/package/php-5.2.14/sapi/apache2handler/sapi_apache2.c:639
经过半个多小时的跟踪, 终于找到原因
是因为, 在PHP中, 对于exit, 其实是借助了set/longjmp来实现用户脚本退出以后, 到达收尾工作, 而对于出错代码出是根据wrapper的err_count计数来确定有多少错误信息要输出.
并且, 在输出完错误信息以后, 清空wrap的错误信息, 置零错误计数.
void php_stream_tidy_wrapper_error_log(php_stream_wrapper *wrapper TSRMLS_DC) { if (wrapper) { /* tidy up the error stack */ int i; for (i = 0; i < wrapper->err_count; i++) { efree(wrapper->err_stack[i]); } if (wrapper->err_stack) { efree(wrapper->err_stack); } wrapper->err_stack = NULL; wrapper->err_count = 0; } }
而, 因为在现实错误信息之后, 会紧接着触发php_error_docref1, 继而触发代码中设置的error_handler, 而在handler中, 却调用了exit, 最终longjmp到了soap处理时刻设置的跳转点, 造成跳过了对 php_stream_tidy_wrapper_error_log 的调用, 所以导致第二次再来请求的时候, err_count并没有正确的被初始化为零, 还是保持着上次请求的错误数.
于是, 在输出错误信息的时候,
...... for (i = 0, l = 0; i < wrapper->err_count; i++) { l += strlen(wrapper->err_stack[i]); //出core了 if (i < wrapper->err_count - 1) { l += brlen; } }
暂时来说, 解决这个办法, 可以在streams的php_stream_display_wrapper_errors函数调用php_error_docref1之前掉后用php_stream_tidy_wrapper_error_log;
我已经提交了 bug, 并提供了PHP-5.2.14的patch
http://bugs.php.net/bug.php?id=52935
建议继续学习:
- 深入理解Nginx之调试优化技巧 (阅读:6903)
- stream.js :一个新的JavaScript数据结构 (阅读:4101)
- 又一个PHP低概率Core的分析(PHP内存管理) (阅读:3430)
- awk之exit (阅读:2937)
- 如何调试PHP的Core之获取基本信息 (阅读:2495)
- 全平台大文件断点续传上传技术 ( 开源项目 Stream ) (阅读:2304)
- 怎样用core文件调试你的linux程序? (阅读:2744)
- 更简单的重现PHP Core的调用栈 (阅读:2171)
- 获取 MySQL 崩溃时的 core file (阅读:1569)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:雪候鸟 来源: 风雪之隅
- 标签: core exit stream
- 发布时间:2010-09-28 09:25:22
- [70] Twitter/微博客的学习摘要
- [65] IOS安全–浅谈关于IOS加固的几种方法
- [65] 如何拿下简短的域名
- [64] find命令的一点注意事项
- [63] Go Reflect 性能
- [63] android 开发入门
- [61] 流程管理与用户研究
- [59] 图书馆的世界纪录
- [59] 读书笔记-壹百度:百度十年千倍的29条法则
- [59] Oracle MTS模式下 进程地址与会话信