Edit report at http://bugs.php.net/bug.php?id=51265&edit=1
ID: 51265
Updated by: tony2...@php.net
Reported by: gotwig at papaya-cms dot com
Summary: Segfault because of wrong memory allocation
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2SVN-2010-03-10 (SVN)
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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] paj...@php.net
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 http://bugs.php.net/bug.php?id=51265&edit=1
