Bug #17588 Updated: array_reduce() crashes

ID: 17588 Updated by: nick@phpa.co.uk Reported By: nick@phpa.co.uk Status: Open Bug Type: Reproducible crash Operating System: Linux glibc 2.1.3 PHP Version: 4.2.1 New Comment: Although in this case the function name was corrupt, checking pointers repeatedly, this is not always the case. Another place to crash is below: Program received signal SIGSEGV, Segmentation fault. 0x813c277 in zif_array_reduce (ht=3, return_value=0x82e62ac, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.3.0dev/ext/standard/array.c:3037 3037 zend_hash_move_forward_ex(Z_ARRVAL_PP(input), &pos); (gdb) p *input $1 = (zval *) 0x2773746e (gdb) p **input Cannot access memory at address 0x2773746e (gdb) The related php code is below, and the memory corruption may be happening elsewhere. function logtime_str() { return strftime('%y%m%d %H%M%S'); } function escape_logstr($msg) { return str_replace(':','\:',$msg); } function build_log_entry($current, $item) { return $current . ':' . escape_logstr($item); } function write_log_entry($filename, $items) { global $siteroot,$logdir; if ($fp = @fopen("$logdir/$filename", "a")) { fwrite($fp, array_reduce($items, "build_log_entry", logtime_str())."\n"); fclose($fp); } } Previous Comments: ------------------------------------------------------------------------ [2002-06-04 05:24:05] nick@phpa.co.uk PHP 4.2.1 and later (and probably before) crash in array_reduce() after a number of page requests. At one point array_reduce() emitted a message concering problems with the callback function, although this was unconditionally defined prior to the call, and had correct arguments. This feels like a return of the problems in 4.0.6, and that went away in 4.0.7 and beyond. The following is the stack trace from a 4.3.0-dev build. Program received signal SIGSEGV, Segmentation fault. call_user_function_ex (function_table=0x824d198, object_pp=0x0, function_name=0x19, retval_ptr_ptr=0xbfff9ef8, param_count=2, params=0xbfff9efc, no_separation=0, symbol_table=0x0) at /usr/local/src/php-4.3.0dev/Zend/zend_execute_API.c:403 403 if (function_name->type==IS_ARRAY) { /* assume array($obj, $name ) couple */ (gdb) where #0 call_user_function_ex (function_table=0x824d198, object_pp=0x0, function_name=0x19, retval_ptr_ptr=0xbfff9ef8, param_count=2, params=0xbfff9efc, no_separation=0, symbol_table=0x0) at /usr/local/src/php-4.3.0dev/Zend/zend_execute_API.c:403 #1 0x813c4d4 in zif_array_reduce (ht=3, return_value=0x838aa44, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-4.3.0dev/ext/standard/array.c:3020 #2 0x80a9e76 in execute (op_array=0x83ae350) at /usr/local/src/php-4.3.0dev/Zend/zend_execute.c:1598 #3 0x80a9fdb in execute (op_array=0x83ad068) at /usr/local/src/php-4.3.0dev/Zend/zend_execute.c:1638 etc. The function name is an invalid zval ptr. When phpa is installed (not in this case), it tends to crash more often, in the same fn, and in that case when iterating an ht. There was an invalid *zval** in that case too. The function table ht passed to call_user_function_ex() seems valid. (gdb) p *function_table $4 = {nTableSize = 1024, nTableMask = 1023, nNumOfElements = 786, nNextFreeElement = 0, pInternalPointer = 0x8230b88, pListHead = 0x8230b88, pListTail = 0x82d5310, arBuckets = 0x8260530, pDestructor = 0x8093f30 <destroy_zend_function>, persistent = 1 '\001', nApplyCount = 0 '\000', bApplyProtection = 0 '\000'} (gdb) Assuming callable is valid after the call to zend_get_parameters_ex, then possibly zend_is_callable() is freeing the zval. I'll poke around further and add more info if I find any. nick ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=17588&edit=1