Edit report at https://bugs.php.net/bug.php?id=51265&edit=1
ID: 51265 Updated by: [email protected] Reported by: gotwig at papaya-cms dot com Summary: Segfault because of wrong memory allocation -Status: Feedback +Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Debian GNU/Linux 4.0 PHP Version: 5.2SVN-2010-03-10 (SVN) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: ------------------------------------------------------------------------ [2010-06-08 14:58:11] [email protected] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. ------------------------------------------------------------------------ [2010-03-12 16:25:44] gotwig at papaya-cms dot com sorry, I have actually no idea how to exactly reproduce a stack reallocation inside of preg_replace_callback with a custom script to help you. I must think about, perhaps some days later. ------------------------------------------------------------------------ [2010-03-12 16:03:39] [email protected] Do you have a script to reproduce this problem? ------------------------------------------------------------------------ [2010-03-12 14:45:12] gotwig at papaya-cms dot com Hallo, my assumption about a wrong sized block allocation has not confirmed, I have the source of the problem now: - it occurs in preg_replace_impl function, - our php code use preg_replace_callback with a static callback to a non-static object method, - this raise an E_STRICT warning where an user defined error handler will be called, - this call reallocates argument stack where some pointers to the previous argument stack frame are already saved in preg_replace_impl and will be used a bit later. Our PHP code likes as following: class PapayaUtilStringUtf8 { ... preg_replace_callback( $pattern, array('PapayaUtilStringUtf8', 'ensureCharCallback'), (string)$string ); ... function ensureCharCallback($charMatch) { ... } } Actual backtrace from reallocation call, where p=0xb70318b0 is argument_stack : #0 _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005 #1 0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at /data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99 #2 0xb76d191e in call_user_function_ex (function_table=0x812b088, object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00, param_count=5, params=0xb6bed450, no_separation=1, symbol_table=0x0) at /data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640 #3 0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 "Non-static method %s::%s() cannot be called statically") at /data/extern/php_svn/php-src-5.2/Zend/zend.c:1041 #4 0xb76e18fe in zend_is_callable_check_func (check_flags=<value optimized out>, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0, callable=0xb6b349f8, ce_ptr=0xbfad9ec4, fptr_ptr=0xbfad9ebc) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204 #5 0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0, check_flags=<value optimized out>, callable_name=0xbfad9f44, callable_name_len=0x0, ce_ptr=0xbfad9ec4, fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332 #6 0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0, callable_name=0xbfad9f44) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363 #7 0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac, return_value_ptr=<value optimized out>, this_ptr=0x0, return_value_used=1, is_callable_replace=1 '\001') at /data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319 ------------------------------------------------------------------------ [2010-03-10 18:43:40] gotwig at papaya-cms dot com Description: ------------ Hallo, I have found a bug in _emalloc logic where an allocation returns a pointer to a cached block smaller than requested; when this block is used some memory after that goes corrupted and we get a segfault. The problem is reproducible with our project code, that is a version of papaya cms, but I am not able to reconstruct all circumstances with an example script to send you, sorry. I am debugging it itself, but need perhaps some help from you to understand how exact does memory allocation works here and where will be such one error possible: such a wrong pointer comes from the case on Lines 1778...1790 in zend_alloc.c : if (EXPECTED(heap->cache[index] != NULL)) { ... also, that is a previously freed cached block, but I have actually no idea where should I look any further. Please, give me some advice. My configuration: PHP Version from http://svn.php.net/repository/php/php-src/branches/PHP_5_2 Revision: 296029 compiled with ./configure --disable-cli --disable-cgi --disable-fastcgi --with-apxs2=/usr/bin/apxs2 --enable-debug --with-mysql --with-xsl OS: Debian GNU/Linux 4.0 I have also tested this problem on a build from actually 5.3 branch, but was not able to reproduce, perhaps because of many changes in another logic there. But if this bug really comes from _zend_mm_alloc_int function their code did not changed in 5.3 and the problem may also occur there. The bug is not critical for our company, we have found a workaround where this will not be triggered any more, but this is of course not a solution an I want to repair it at the source. Thank you in advance, Viktor Gotwig. Actual result: -------------- My Debuging: br /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1761 #0 _zend_mm_alloc_int (heap=0x81de2a0, size=41) at /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1761 #1 0xb767fbb5 in zend_is_callable_ex (callable=0xb6c420cc, check_flags=0, callable_name=0xbf87c2f4, callable_name_len=0xbf87c278, ce_ptr=0xbf87c274, fptr_ptr=0xbf87c26c, zobj_ptr_ptr=0xbf87c268) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2287 #2 0xb767ff97 in zend_is_callable (callable=0xb6c420cc, check_flags=0, callable_name=0xbf87c2f4) at /data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363 #3 0xb74bd2a4 in preg_replace_impl (ht=3, return_value=0xb6c42290, return_value_ptr=<value optimized out>, this_ptr=0x0, return_value_used=1, is_callable_replace=1 '\001') at /data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319 (gdb) x/21wx 0x81de2a0 0x81de2a0: 0x00000001 0x00000002 0x00025000 0x00040000 0x81de2b0: 0x00200000 0xb6b89008 0x0818b4f0 0x00340000 0x81de2c0: 0x00340000 0x08000000 0x00306030 0x0030c124 0x81de2d0: 0x00002000 0xb6fcd018 0x00000000 0x00000000 0x81de2e0: 0x00001bfc 0xb6c2b22c 0xb6c41b10 0x00000000 0x81de2f0: 0xb6c41f50 until /data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:1934 (gdb) p/x $eax $8 = 0xb6c4207c (gdb) x/21wx 0x81de2a0 0x81de2a0: 0x00000001 0x00000002 0x00025000 0x00040000 0x81de2b0: 0x00200000 0xb6b89008 0x0818b4f0 0x00340000 0x81de2c0: 0x00340000 0x08000000 0x00306030 0x0030c124 0x81de2d0: 0x00002000 0xb6fcd018 0x00000000 0x00000000 0x81de2e0: 0x00001bc8 0xb6c2b22c 0xb6c41b10 0x00000000 0x81de2f0: 0xb6c41f50 (gdb) x/20wx $eax-8 0xb6c42074: 0x00000035 0x00000019 0x00000000 0x74556179 0xb6c42084: 0x74536c69 0x676e6972 0x38667455 0x6e653a3a 0xb6c42094: 0x65727573 0x72616843 0x6c6c6143 0x6b636162 0xb6c420a4: 0x5c2d3000 0x0000001d 0x00000035 0x00000000 0xb6c420b4: 0x68636572 0x61637261 0x61626c6c 0x20006b63 (gdb) x/s 0xb6c42080 0xb6c42080: "yaUtilStringUtf8::ensureCharCallback" ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=51265&edit=1
