Bug #51265 [Opn-Fbk]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=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
Bug #51265 [Opn-Fbk]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=1
ID: 51265
Updated by: paj...@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:
Do you have a script to reproduce this problem?
Previous Comments:
[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
