PHP stream未能及时清理现场导致Core的bug

光明使者

1. 在使用set_error_handler的时候, 能100%重现的core, 提炼后的重现代码如下(环境必须不能访问internet):
   
2.             
   
3.            　　<?php
   
4.            　　function err_handler(){
   
5.            　　exit;
   
6.            　　return true;
   
7.            　　}
   
8.            　　set_error_handler('err_handler');
   
9.            　　$client = file_get_contents('http://www.laruence.com/ServiceNoWse.asmx?WSDL');
   
10.             
    
11.            　　这段代码, 放在webServer中, 第一次访问不会有事, 第二第三次的时候就会出core.
    
12.            　　gdb跟踪以后发现, core出在php_stream_display_wrapper_errors函数中, 对err_stack中的错误信息字符串做处理的时刻, core的堆栈如下:
    
13.             
    
14.            　　#0 0x000000302af6ff20 in strlen () from /lib64/tls/libc.so.6
    
15.            　　#1 0x0000002a989d97c1 in php_stream_display_wrapper_errors (wrapper=0x2a98e884a0, path=Variable 'path' is not available.
    
16.            　　) at /home/huixc/package/php-5.2.14/main/streams/streams.c:151
    
17.            　　#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,
    
18.            　　context=0x76e808) at /home/huixc/package/php-5.2.14/main/streams/streams.c:1893
    
19.            　　#3 0x0000002a98966541 in zif_file_get_contents (ht=-1729541984, return_value=0x76e738, return_value_ptr=Variable 'return_value_ptr' is not available.
    
20.            　　) at /home/huixc/package/php-5.2.14/ext/standard/file.c:541
    
21.            　　#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
    
22.            　　#5 0x0000002a98a2b671 in execute (op_array=0x769890) at /home/huixc/package/php-5.2.14/Zend/zend_vm_execute.h:92
    
23.            　　#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
    
24.            　　#7 0x0000002a989c965d in php_execute_script (primary_file=0x7fbfffef00) at /home/huixc/package/php-5.2.14/main/main.c:2036
    
25.            　　#8 0x0000002a98a9bd36 in php_handler (r=0x8f1ba8) at /home/huixc/package/php-5.2.14/sapi/apache2handler/sapi_apache2.c:639
    
26.             
    
27.            　　经过半个多小时的跟踪, 终于找到原因
    
28.            　　是因为, 在PHP中, 对于exit, 其实是借助了set/longjmp来实现用户脚本退出以后, 到达收尾工作, 而对于出错代码出是根据wrapper的err_count计数来确定有多少错误信息要输出.
    
29.            　　并且, 在输出完错误信息以后, 清空wrap的错误信息, 置零错误计数.
    
30.             
    
31.            　　void php_stream_tidy_wrapper_error_log(php_stream_wrapper *wrapper TSRMLS_DC)
    
32.            　　{
    
33.            　　if (wrapper) {
    
34.            　　/* tidy up the error stack */
    
35.            　　int i;
    
36.            　　for (i = 0; i < wrapper->err_count; i++) {
    
37.            　　efree(wrapper->err_stack[i]);
    
38.            　　}
    
39.            　　if (wrapper->err_stack) {
    
40.            　　efree(wrapper->err_stack);
    
41.            　　}
    
42.            　　wrapper->err_stack = NULL;
    
43.            　　wrapper->err_count = 0;
    
44.            　　}
    
45.            　　}
    
46.             
    
47.            　　而, 因为在现实错误信息之后, 会紧接着触发php_error_docref1, 继而触发代码中设置的error_handler, 而在handler中, 却调用了exit, 最终longjmp到了soap处理时刻设置的跳转点, 造成跳过了对 php_stream_tidy_wrapper_error_log 的调用, 所以导致第二次再来请求的时候, err_count并没有正确的被初始化为零, 还是保持着上次请求的错误数.
    
48.            　　于是, 在输出错误信息的时候,
    
49.             
    
50.            　　......
    
51.            　　for (i = 0, l = 0; i < wrapper->err_count; i++) {
    
52.            　　l += strlen(wrapper->err_stack[i]); //出core了
    
53.            　　if (i < wrapper->err_count - 1) {
    
54.            　　l += brlen;
    
55.            　　}
    
56.            　　}
    
57.             
    
58.            　　暂时来说, 解决这个办法, 可以在streams的php_stream_display_wrapper_errors函数调用php_error_docref1之前掉后用php_stream_tidy_wrapper_error_log;

复制代码

猫性男孩

楼主辛苦了，楼主好人