PHP stream failed to clean up the site in time to cause core bugs

Colleagues have found a core that can reproduce 100% when using Set_error_handler (the environment must not have access to the Internet) after refining the following code:

<?php

function Err_handler () {

Exit

return true;

}

Set_error_handler (' Err_handler ');

$client = file_get_contents ("Http://www.laruence.com/ServiceNoWse.asmx?WSDL");

This code, put in the webserver, the first visit will be fine, the second third time will be the core.

GDB tracking later found that core out in the Php_stream_display_wrapper_errors function, the error message string in Err_stack processing time, the core stack is as follows:

#0 0x000000302af6ff20 in strlen () from/lib64/tls/libc.so.6

#1 0x0000002a989d97c1 in Php_stream_display_wrapper_errors (wrapper=0x2a98e884a0, path=variable "path" are 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

After half an hour of tracking, I finally found out why.

is because, in PHP, for exit, in fact, is the use of set/longjmp to implement the user script exit after the end of the work, and the error code is based on the wrapper err_count count to determine how much error information to output.

Also, after outputting the error message, empty The wrap error message and place the 0 error count.

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;

}

}

And, because after the real error message, it triggers the PHP_ERROR_DOCREF1, then triggers the set of Error_Handler in the code, and in handler, it calls exit, which eventually longjmp to the point at which the soap processing time is set, caused the call to skip over the Php_stream_tidy_wrapper_error_log, so that when the second request was made, the err_count was not properly initialized to zero, or the last requested error was maintained.

So, when you output the error message,

......

for (i = 0, l = 0; i < wrapper->err_count; i++) {

L + + strlen (Wrapper->err_stack[i]); Out of the core.

if (I < wrapper->err_count-1) {

L + + Brlen;

}

}

For the time being, this solution can be used before the streams php_stream_display_wrapper_errors function calls PHP_ERROR_DOCREF1 Php_stream_tidy_wrapper_ Error_log;