Bug #60701 [Com]: __toString() which stores $this reference triggers segfault (with fix!)
Edit report at https://bugs.php.net/bug.php?id=60701edit=1
ID: 60701
Comment by: pada at hrz dot tu-chemnitz dot de
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault (with fix!)
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: CentOS
PHP Version:5.3.8
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
This patch does not work for me. I'm still experiencing SegFaults with the
following code on CentOS 6.0 with php 5.3.3 and
https://bugs.php.net/patch-display.php?bug_id=60701patch=bug60701.patchrevision=1327066212
applied.
Test-Script:
?php
class C{function f(){$this-o=new O();return$this-o;}function
__destruct(){}}class O{function __toString(){$this-$this;}}$c=new
C();$o=$c-f();trim($o);
?
With the patch applied, I'm still getting SegFaults in
/var/log/httpd/error_log, but no coredumps any more. This is very strange,
since coredumping is correctly configured and with other reproducer scripts
from other bugs I'm getting coredumps.
Previous Comments:
[2012-02-11 00:49:07] andrew at localcoast dot net
I can produce a similar issue on PHP 5.3.10 on Ubuntu 10.04 LTS x86_64 with the
patch applied. However, the initial test script provided in the first comment
runs without trouble.
Here's the backtrace for the issue I am having:
http://paste2.org/p/1900387
#0 0x7f71fa9b8d11 in gc_zval_possible_root (zv=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_gc.c:143
#1 0x7f71fa9a777b in zend_hash_destroy (ht=0x7f7201496908) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_hash.c:529
p = 0x7f7201497c58
#2 0x7f71fa9ba379 in zend_object_std_dtor (object=0x7f7201497428) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:45
#3 0x7f71fa9ba399 in zend_objects_free_object_storage
(object=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:126
#4 0x7f71fa9bdba8 in zend_objects_store_free_object_storage
(objects=0x7f71fb162a18) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects_API.c:92
i = 626
#5 0x7f71fa98ebfb in shutdown_executor () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_execute_API.c:304
__bailout = {{__jmpbuf = {140127520564832, -3282099667358606386,
140127614418320, 0, -4294967295, 140127589456664, -3211606770996110386,
-3282099660654535730}, __mask_was_saved = 0, __saved_mask = {__val =
{140127612053568, 96, 140127512287676,
140127629890216, 140127638595144, 88, 140127512287676, 592,
140127512287676, 140127520566336, 140127520563352, 140127520564648, 0,
18446744069414584321, 140127512403989, 140127520566336
#6 0x7f71fa99b612 in zend_deactivate () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend.c:891
#7 0x7f71fa947ad5 in php_request_shutdown (dummy=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/main/main.c:1661
report_memleaks = 1 '\001'
#8 0x7f71faa24a97 in php_apache_request_dtor (r=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:509
#9 php_handler (r=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:681
ctx = 0x7f7200ae5840
conf = 0x7f7200689c98
brigade = 0x7f7200ae6658
bucket = value optimized out
rv = value optimized out
parent_req = 0x0
#10 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:159
n = 6
rv = -2039876096
#11 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x7f7200ad61d8 Xa\255
result = 11362776
old_handler = 0x7f7200792ec8 application/x-httpd-php
ignore = value optimized out
#12 0x7f71ff0f45fc in ap_internal_redirect (new_uri=value optimized out,
r=value optimized out) at
/build/buildd/apache2-2.2.14/modules/http/http_request.c:501
new = 0x7f7200ae3d90
access_status = -2039876096
#13 0x7f71f664dc95 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
No symbol table info available.
#14 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ad61d8) at
/build/buildd/apache2-2.2.14/server/config.c:159
n = 7
rv = -2039876096
#15 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ad61d8) at
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x0
result = 0
old_handler = 0x7f71f6651e58 redirect-handler
ignore = value optimized out
#16 0x7f71ff0f47d8
Bug #60701 [Com]: __toString() which stores $this reference triggers segfault (with fix!)
Edit report at https://bugs.php.net/bug.php?id=60701edit=1
ID: 60701
Comment by: pada at hrz dot tu-chemnitz dot de
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault (with fix!)
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: CentOS
PHP Version:5.3.8
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
@sjon: Now, I retried with the original Test script from daan.
This patch works for me too, thanks :)
Previous Comments:
[2012-02-13 19:16:25] sjon at hortensius dot net
@andrew at localcoast dot net
Did you try to remove all __toString methods from your application? If that
didn't fix it you are experiencing another bug and will probably need to
generate
a small reproducing script yourself
@pada at hrz dot tu-chemnitz dot de
your problem has nothing to do with this bug, You are simply demonstrating a
recursive loop.
[2012-02-13 18:00:01] pada at hrz dot tu-chemnitz dot de
This patch does not work for me. I'm still experiencing SegFaults with the
following code on CentOS 6.0 with php 5.3.3 and
https://bugs.php.net/patch-display.php?bug_id=60701patch=bug60701.patchrevision=1327066212
applied.
Test-Script:
?php
class C{function f(){$this-o=new O();return$this-o;}function
__destruct(){}}class O{function __toString(){$this-$this;}}$c=new
C();$o=$c-f();trim($o);
?
With the patch applied, I'm still getting SegFaults in
/var/log/httpd/error_log, but no coredumps any more. This is very strange,
since coredumping is correctly configured and with other reproducer scripts
from other bugs I'm getting coredumps.
[2012-02-11 00:49:07] andrew at localcoast dot net
I can produce a similar issue on PHP 5.3.10 on Ubuntu 10.04 LTS x86_64 with the
patch applied. However, the initial test script provided in the first comment
runs without trouble.
Here's the backtrace for the issue I am having:
http://paste2.org/p/1900387
#0 0x7f71fa9b8d11 in gc_zval_possible_root (zv=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_gc.c:143
#1 0x7f71fa9a777b in zend_hash_destroy (ht=0x7f7201496908) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_hash.c:529
p = 0x7f7201497c58
#2 0x7f71fa9ba379 in zend_object_std_dtor (object=0x7f7201497428) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:45
#3 0x7f71fa9ba399 in zend_objects_free_object_storage
(object=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:126
#4 0x7f71fa9bdba8 in zend_objects_store_free_object_storage
(objects=0x7f71fb162a18) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects_API.c:92
i = 626
#5 0x7f71fa98ebfb in shutdown_executor () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_execute_API.c:304
__bailout = {{__jmpbuf = {140127520564832, -3282099667358606386,
140127614418320, 0, -4294967295, 140127589456664, -3211606770996110386,
-3282099660654535730}, __mask_was_saved = 0, __saved_mask = {__val =
{140127612053568, 96, 140127512287676,
140127629890216, 140127638595144, 88, 140127512287676, 592,
140127512287676, 140127520566336, 140127520563352, 140127520564648, 0,
18446744069414584321, 140127512403989, 140127520566336
#6 0x7f71fa99b612 in zend_deactivate () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend.c:891
#7 0x7f71fa947ad5 in php_request_shutdown (dummy=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/main/main.c:1661
report_memleaks = 1 '\001'
#8 0x7f71faa24a97 in php_apache_request_dtor (r=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:509
#9 php_handler (r=value optimized out) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:681
ctx = 0x7f7200ae5840
conf = 0x7f7200689c98
brigade = 0x7f7200ae6658
bucket = value optimized out
rv = value optimized out
parent_req = 0x0
#10 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:159
n = 6
rv = -2039876096
#11 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x7f7200ad61d8 Xa\255
result = 11362776
old_handler = 0x7f7200792ec8 application/x-httpd-php
ignore = value optimized out
#12 0x7f71ff0f45fc in ap_internal_redirect
#47365 [Com]: ip2long: 32bis vs. 64bit!
ID: 47365
Comment by: pada at hrz dot tu-chemnitz dot de
Reported By: flobee at gmail dot com
Status: No Feedback
Bug Type: *Network Functions
Operating System: SunOS
PHP Version: 5.2.9RC1
New Comment:
Hi,
I can confirm the bug on Solaris (not OpenSolaris) Version 10 x86_64
# isainfo -b
64
# uname -srvmpi
SunOS 5.10 Generic_118855-33 i86pc i386 i86pc
# Results with unpatched 64 Bit PHP 5.2.8:
# php5 -r var_dump(ip2long('example.com'));
int(4294967295) # WRONG, should be bool(false), this is not a valid IP
# php5 -r var_dump(ip2long(\1\x00x\));
int(1) # correct?
# php5 -r var_dump(ip2long('0.1'));
int(1) # correct?
# php5 -r var_dump(ip2long(''));
bool(false) # correct
# php5 -r var_dump(ip2long('0.0.0.0'));
int(0) # correct
# php5 -r var_dump(ip2long('0.0.0.1'));
int(1) # correct
# php5 -r var_dump(ip2long('1.2.3.4'));
int(16909060) # correct
# php5 -r var_dump(ip2long('4.3.2.1'));
int(67305985) # correct
# php5 -r var_dump(ip2long('255.255.255.254'));
int(4294967294) # correct
# php5 -r var_dump(ip2long('255.255.255.255'));
int(4294967295) # correct
There is a problem in PHP function ip2long() with the comparison with
INADDR_NONE on 64 bit Solaris systems, since the return value of
function inet_addr is stored in an unsigned long int variable while
struct inet_addr is only 32 bit wide. The RETURN_FALSE branch will
never be reached when a string like example.com is supplied, since the
comparison of ip and INADDR_NONE evaluates to false (it should be true
in case of error).
# Patch worked as expected on Debian GNU/Linux squeeze x86_64 with PHP
5.2.6:
# php5 -r var_dump(ip2long('example.com'));
bool(false) # correct
# php5 -r var_dump(ip2long(\1\x00x\));
int(1) # correct?
# php5 -r var_dump(ip2long('0.1'));
int(1) # correct?
# php5 -r var_dump(ip2long(''));
bool(false) # correct
# php5 -r var_dump(ip2long('0.0.0.0'));
int(0) # correct
# php5 -r var_dump(ip2long('0.0.0.1'));
int(1) # correct
# php5 -r var_dump(ip2long('1.2.3.4'));
int(16909060) # correct
# php5 -r var_dump(ip2long('4.3.2.1'));
int(67305985) # correct
# php5 -r var_dump(ip2long('255.255.255.254'));
int(4294967294) # correct
# php5 -r var_dump(ip2long('255.255.255.255'));
int(4294967295) # correct
I propose the following patch to simplify the code and fix the problem
at the same time. Will this code work on all platforms (Linux, Solaris,
BSD, Windows, etc.)? Your hints and suggestions are welcome.
start of patch
diff -ru php-5.2.9.orig/ext/standard/basic_functions.c
php-5.2.9/ext/standard/basic_functions.c
--- php-5.2.9.orig/ext/standard/basic_functions.c 2008-12-31
12:17:44.0 +0100
+++ php-5.2.9/ext/standard/basic_functions.c 2009-03-25
19:00:15.0 +0100
@@ -97,10 +97,6 @@
# include win32/unistd.h
#endif
-#ifndef INADDR_NONE
-#define INADDR_NONE ((unsigned long int) -1)
-#endif
-
#include zend_globals.h
#include php_globals.h
#include SAPI.h
@@ -4336,7 +4332,7 @@
PHP_FUNCTION(ip2long)
{
zval **str;
- unsigned long int ip;
+ struct in_addr addr;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, str) ==
FAILURE) {
WRONG_PARAM_COUNT;
@@ -4344,20 +4340,11 @@
convert_to_string_ex(str);
- if (Z_STRLEN_PP(str) == 0 || (ip = inet_addr(Z_STRVAL_PP(str))) ==
INADDR_NONE) {
- /* the only special case when we should return -1 ourselves,
-* because inet_addr() considers it wrong. We return 0x
and
-* not -1 or ~0 because of 32/64bit issues.
-*/
- if (Z_STRLEN_PP(str) == sizeof(255.255.255.255) - 1
- !memcmp(Z_STRVAL_PP(str), 255.255.255.255,
sizeof(255.255.255.255) - 1)) {
- RETURN_LONG(0x);
- }
-
- RETURN_FALSE;
- }
+ if (Z_STRLEN_PP(str) == 0 || inet_pton(AF_INET, Z_STRVAL_PP(str),
addr) != 1) {
+RETURN_FALSE;
+ }
- RETURN_LONG(ntohl(ip));
+ RETURN_LONG(ntohl(addr.s_addr));
}
/* }}} */
end of patch
Kind regards,
Daniel
Previous Comments:
[2009-02-20 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-02-12 13:09:49] d...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
Which Solaris Version. Solaris 10. On Sparc or on x86?
On OpenSolaris x86 64 bit it returns false as expected:
~/ php -r var_dump(ip2long('web.de'));
bool(false)
~/ isainfo -b
