Bug #65284 [Com]: Segmentation fault with the CLI
Edit report at https://bugs.php.net/bug.php?id=65284edit=1
ID: 65284
Comment by: sjon at hortensius dot net
Reported by:jhaagsma at gmail dot com
Summary:Segmentation fault with the CLI
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
Obviously a vanilla 5.4.17 doesn't crash with this script (as can easily be
seen
at http://3v4l.org/gBq9U ); so the problem must be your environment; or the
patches that were applied.
I think you're best of contacting your distro-specific maintainer for this (I
noticed several debian patches which could cause this behaviour)
Previous Comments:
[2013-07-18 07:17:28] jhaagsma at gmail dot com
Description:
I was updating my machine VM's from 5.4.17RC1 to 5.4.17 and noticed a
problem,
it was segfaulting.
Using this test file on an upgraded machine and non-upgraded machine:
machine1:~$ php --version
PHP 5.4.17RC1 (cli) (built: Jun 22 2013 19:27:26)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
machine1:~$ php testphp
Running from CLI
machine2:~$ php --version
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
machine2:~$ php testphp
Segmentation fault (core dumped)
This is on ubuntu using Ondrej's PPA for PHP 5.4, but he said he's not made any
debian/ubuntu specific changes since RC1.
Test script:
---
?php
if(defined('STDIN') )
echo(Running from CLI);
else
echo(Not Running from CLI);
?
Expected result:
Expected result was Running from CLI
Actual result:
--
Segmentation fault (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65284edit=1
Bug #64896 [Com]: Segfault with gc_collect_cycles using unserialize on certain objects
Edit report at https://bugs.php.net/bug.php?id=64896edit=1 ID: 64896 Comment by: sjon at hortensius dot net Reported by:mark dot chong at acquireap dot com Summary:Segfault with gc_collect_cycles using unserialize on certain objects Status: Open Type: Bug Package:Reproducible crash Operating System: ubuntu PHP Version:5.4.15 Block user comment: N Private report: N New Comment: @laruence I can reproduce this easily, see http://3v4l.org/Z9Bg7#v545 every version of PHP since 5.4.5 segfaults on the script (without xdebug) here is your backtrace without xdebug: #0 0x00608737 in ?? () #1 0x0061f349 in _zval_ptr_dtor () #2 0x0063b8d8 in zend_hash_destroy () #3 0x0062d37b in _zval_dtor_func () #4 0x0069e31d in ?? () #5 0x0065508f in execute () #6 0x00621190 in zend_call_function () #7 0x00644e55 in zend_call_method () #8 0x0064eab2 in zend_objects_destroy_object () #9 0x0064c9a8 in gc_collect_cycles () #10 0x0063e699 in ?? () #11 0x006d6d6c in ?? () #12 0x0065508f in execute () #13 0x0062fb94 in zend_execute_scripts () #14 0x005d1afc in php_execute_script () #15 0x006d8d1f in ?? () #16 0x0042615d in ?? () #17 0x7690fa15 in __libc_start_main () from /usr/lib/libc.so.6 #18 0x004261f9 in _start () With a debug-build; this problem seems unreproducable Previous Comments: [2013-05-24 13:23:43] larue...@php.net please disable xdebug then try again [2013-05-24 01:21:08] edward dot savage at dodo dot com With the given test case I get the segfault as described (Ubuntu 13.04/PHP 5.4.9-4ubuntu2). I found that I could work around it by adding a function like 'usleep(1);' or '$var = 2;' between global and the $bar operation in the destructor. A simple operation like '6^123;', even repeated at length, wasn't enough to avoid the fault. Once the test case was running without crashing I started looking at the array assignment to $bar. I found that printing the result of $bar after the destructor ran showed that the values of $this-_private were lost from the global $bar. Even more information is lost when gc_collect_cycles is executed. It can be shown to only be the values as an assigned multidimensional array will retain its keys. This loss of data and the segfault can be avoided by moving the $bar assignment into a pseudo destructor or by removing the circular reference. However, for the reported case there is definitely a data integrity issue when assigning an array to a global in a __destruct with a circular reference present. I could not repeat this issue with other types of assignment like string and object. [2013-05-22 08:42:45] mark dot chong at acquireap dot com I have run the test case on 3 different machines which call caused a segfault, bellow is the bt from one of them #0 _zend_mm_free_int (heap=0xe09290, p=0x77e793a8) at /tmp/buildd/php5- 5.4.15/Zend/zend_alloc.c:2100 #1 0x0068d97a in _zval_dtor (zvalue=optimised out) at /tmp/buildd/php5-5.4.15/Zend/zend_variables.h:35 #2 _zval_ptr_dtor (zval_ptr=0x77e779a0) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute_API.c:438 #3 _zval_ptr_dtor (zval_ptr=0x77e779a0) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute_API.c:427 #4 0x006aab38 in zend_hash_destroy (ht=0x77e778e0) at /tmp/buildd/php5-5.4.15/Zend/zend_hash.c:560 #5 0x0069b8fb in _zval_dtor_func (zvalue=0x7fffa5a0) at /tmp/buildd/php5-5.4.15/Zend/zend_variables.c:45 #6 0x00718e7d in zend_assign_to_variable (value=0x77e776d8, variable_ptr_ptr=0x77e40410) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute.c:937 #7 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x77e40378) at /tmp/buildd/php5-5.4.15/Zend/zend_vm_execute.h:33084 #8 0x006feaa7 in execute (op_array=0x77e76af0) at /tmp/buildd/php5- 5.4.15/Zend/zend_vm_execute.h:410 #9 0x7400fa81 in xdebug_execute (op_array=0x77e76af0) at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1391 #10 0x0068f7e0 in zend_call_function (fci=fci@entry=0x7fffa970, fci_cache=0x77e73bb0, fci_cache@entry=0x7fffa940) at /tmp/buildd/php5-5.4.15/Zend/zend_execute_API.c:958 #11 0x006b4115 in zend_call_method (object_pp=object_pp@entry=0x7fffaa28, obj_ce=optimised out, fn_proxy=fn_proxy@entry=0x7fffaa20, function_name=function_name@entry=0xaa42a0 __destruct, function_name_len=function_name_len@entry=10, retval_ptr_ptr=retval_ptr_ptr@entry=0x0, param_count=param_count@entry=0, arg1=arg1@entry=0x0
Bug #64938 [Opn]: libxml_disable_entity_loader setting is shared between threads
Edit report at https://bugs.php.net/bug.php?id=64938edit=1 ID: 64938 User updated by:Sjon at hortensius dot net Reported by:Sjon at hortensius dot net -Summary:libxml_disable_entity_loader setting is shared between hits +Summary:libxml_disable_entity_loader setting is shared between threads Status: Open Type: Bug Package:FPM related Operating System: Archlinux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Clarified summary Previous Comments: [2013-05-29 07:21:46] sjon at hortensius dot net Related To: Bug #62577 [2013-05-28 13:43:33] Sjon at hortensius dot net Description: The libxml_disable_entity_loader() setting is shared between hits in a FPM process. Therefore; our script have the external entity-loader randomly enabled/disabled. Test script: --- ?php die(var_dump(libxml_disable_entity_loader(false))); Expected result: The default setting (which is true since 5.4.13) should always be var_dump-ed Actual result: -- since this setting is remembered in the thread; after a while all hits return false -- Edit this bug report at https://bugs.php.net/bug.php?id=64938edit=1
Bug #62577 [Com]: simplexml_load_file does not file if libxml_disable_entity_loader(true)
Edit report at https://bugs.php.net/bug.php?id=62577edit=1
ID: 62577
Comment by: Sjon at hortensius dot net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:simplexml_load_file does not file if
libxml_disable_entity_loader(true)
Status: Assigned
Type: Bug
Package:SimpleXML related
Operating System: All
PHP Version:master-Git-2012-07-16 (Git)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
I can confirm this issue; it is very annoying and unexpected. Can't the code,
as
a work-around use file-get-contents + simplexml_load_string internally?
This issue is also related to #22215 imo
Previous Comments:
[2012-11-15 11:03:10] paj...@php.net
hi Rob!
What would be the best/cleanest fix for this issue? It affects quite a lot of
apps
out there.
Thanks!
[2012-07-16 09:25:29] ivan dot enderlin at hoa-project dot net
I think it's not a normal behavior.
[2012-07-16 09:22:31] jpa...@php.net
http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#1058
libxml_disable_entity_loader(true) registers a NULL function
(http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#372) as callback for URI
input file handling in libxml.
So you cant open any file with libxml after having called this function.
Is that the correct behavior ? I have no clue to answer that
[2012-07-16 08:56:06] ivan dot enderlin at hoa-project dot net
Description:
The function simplexml_load_file() failed to open any file (existing or not) if
libxml_disable_entity_loader(true) has been called.
I have tried with simplexml_load_string(), it works; same with new
SimpleXMLElement() etc. The bug is restricted to the simplexml_load_file()
function.
Test script:
---
?php
libxml_use_internal_errors(true);
libxml_disable_entity_loader(true);
$xml = simplexml_load_file('foo');
print_r(libxml_get_errors());
var_dump($xml);
Expected result:
Array
(
)
â¦
Actual result:
--
Array
(
[0] = LibXMLError Object
(
[level] = 1
[code] = 1549
[column] = 0
[message] = failed to load external entity foo
[file] =
[line] = 0
)
)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62577edit=1
Bug #62577 [Com]: simplexml_load_file does not file if libxml_disable_entity_loader(true)
Edit report at https://bugs.php.net/bug.php?id=62577edit=1
ID: 62577
Comment by: sjon at hortensius dot net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:simplexml_load_file does not file if
libxml_disable_entity_loader(true)
Status: Assigned
Type: Bug
Package:SimpleXML related
Operating System: All
PHP Version:master-Git-2012-07-16 (Git)
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
I can confirm this issue; it is very annoying and unexpected. Can't the code,
as
a work-around use file-get-contents + simplexml_load_string internally?
This issue is also related to bug #64938 imo
Previous Comments:
[2013-05-29 07:20:39] Sjon at hortensius dot net
I can confirm this issue; it is very annoying and unexpected. Can't the code,
as
a work-around use file-get-contents + simplexml_load_string internally?
This issue is also related to #22215 imo
[2012-11-15 11:03:10] paj...@php.net
hi Rob!
What would be the best/cleanest fix for this issue? It affects quite a lot of
apps
out there.
Thanks!
[2012-07-16 09:25:29] ivan dot enderlin at hoa-project dot net
I think it's not a normal behavior.
[2012-07-16 09:22:31] jpa...@php.net
http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#1058
libxml_disable_entity_loader(true) registers a NULL function
(http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#372) as callback for URI
input file handling in libxml.
So you cant open any file with libxml after having called this function.
Is that the correct behavior ? I have no clue to answer that
[2012-07-16 08:56:06] ivan dot enderlin at hoa-project dot net
Description:
The function simplexml_load_file() failed to open any file (existing or not) if
libxml_disable_entity_loader(true) has been called.
I have tried with simplexml_load_string(), it works; same with new
SimpleXMLElement() etc. The bug is restricted to the simplexml_load_file()
function.
Test script:
---
?php
libxml_use_internal_errors(true);
libxml_disable_entity_loader(true);
$xml = simplexml_load_file('foo');
print_r(libxml_get_errors());
var_dump($xml);
Expected result:
Array
(
)
â¦
Actual result:
--
Array
(
[0] = LibXMLError Object
(
[level] = 1
[code] = 1549
[column] = 0
[message] = failed to load external entity foo
[file] =
[line] = 0
)
)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62577edit=1
Bug #27792 [Com]: [PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir)
Edit report at https://bugs.php.net/bug.php?id=27792edit=1 ID: 27792 Comment by: Sjon at hortensius dot net Reported by:kode at kodekrash dot com Summary:[PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir) Status: Critical Type: Bug Package:Filesystem function related Operating System: * (LFS) PHP Version:5.*, 6CVS (2009-04-30) Block user comment: N Private report: N New Comment: According to http://3v4l.org/sBClC; this is not a problem on a 64 bits linux machine (on any php version). I propose (since this bug obviously won't be fixed) to close this issue and tell people to use 64 bits machines instead of trying to get LFS support in PHP Previous Comments: [2012-08-09 13:28:31] adu at rdsor dot ro @marcb I tested it in PHP 5.4.0 (cli) (built: Apr 12 2012 13:02:59)) on Ubuntu 12.04 kernel 3.0.0-19 i686 and the BUG is still here. Reproduced code: $fname = 'file_of_7GB'; var_dump(filesize( $fname )); // PHP Warning: filesize(): stat failed for file_of_7GB in php_bug_27792.php on line 4 // dumps bool(false) var_dump(is_file( $fname )); // dumps bool(false) var_dump(is_dir( $fname )); // dumps bool(false) $fname = 'file_of_354MB'; var_dump(filesize( $fname )); // dumps int(370336155) var_dump(is_file( $fname )); // dumps bool(true) var_dump(is_dir( $fname )); // dumps bool(false) [2011-01-05 04:46:23] marcb at voicemeup dot com Is anyone able to confirm if this was fixed in any of the 5.X branch ? This is a pretty stupid problem to have to deal with ! [2009-11-12 10:27:45] boite dot pour dot spam at gmail dot com The patch from Wez doesn't work, as it assumes size_t are 64 bits, which is not the case, even when LFS is defined. The patch from Mail Pourri works on 5.3.0 (I haven't tested in 5.3.1) [2009-09-14 08:59:36] j...@php.net The latest patch for this: http://www.php.net/~wez/lfs.diff [2009-07-11 13:40:57] mail dot pourri at laposte dot net Please see fix in http://bugs.php.net/bug.php?id=48886 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=27792 -- Edit this bug report at https://bugs.php.net/bug.php?id=27792edit=1
Bug #64868 [Com]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
Edit report at https://bugs.php.net/bug.php?id=64868edit=1 ID: 64868 Comment by: Sjon at hortensius dot net Reported by:martin dot schuette at icans-gmbh dot com Summary:segfault in zval_mark_grey(), Zend/zend_gc.c:421 Status: Open Type: Bug Package:Reproducible crash Operating System: Debian Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Well pinpointing this should be easy; open PHPUnit_Util_Test and look for the usage of REGEX_REQUIRES (which is in your trace). Var dump the parameters and tell us which ones were passed that caused that caused the segfault? Previous Comments: [2013-05-21 10:09:13] martin dot schuette at icans-gmbh dot com So far I was unable to reproduce the crash with a smaller code sample (i.e. without requiring our complete application and test suite). [2013-05-17 10:57:43] larue...@php.net could you please provide a reproduce test script? thanks [2013-05-17 10:47:30] martin dot schuette at icans-gmbh dot com Description: As part of a PHPUnit test suite I get this segfault. Interestingly it depends on phpunit's command line options. Segfault with phpunit -c app/phpunit.xml.dist --log-junit /dev/null No problem with phpunit -c app/phpunit.xml.dist and phpunit -c app/phpunit.xml.dist --log-junit /dev/null --debug Without GC it works as well: php -dzend.enable_gc=0 /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null Expected result: complete PHPUnit run Actual result: -- deploy@jenkins:/tmp/gitphp -v PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies deploy@jenkins:/tmp/gitgdb --args php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php5...done. done. (gdb) run Starting program: /usr/bin/php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). [New Thread 0x7fffe80d8700 (LWP 27679)] [Thread 0x7fffe80d8700 (LWP 27679) exited] PHPUnit 3.7.10 by Sebastian Bergmann. Configuration read from /tmp/git/app/phpunit.xml.dist . 61 / 3421 ( 1%) ...S. 122 / 3421 ( 3%) . 183 / 3421 ( 5%) . 244 / 3421 ( 7%) . 305 / 3421 ( 8%) . 366 / 3421 ( 10%) . 427 / 3421 ( 12%) . 488 / 3421 ( 14%) . 549 / 3421 ( 16%) . 610 / 3421 ( 17%) . 671 / 3421 ( 19%) . 732 / 3421 ( 21
[PHP-BUG] Bug #64938 [NEW]: libxml_disable_entity_loader setting is shared between hits
From: Sjon at hortensius dot net Operating system: Archlinux PHP version: 5.4.15 Package: FPM related Bug Type: Bug Bug description:libxml_disable_entity_loader setting is shared between hits Description: The libxml_disable_entity_loader() setting is shared between hits in a FPM process. Therefore; our script have the external entity-loader randomly enabled/disabled. Test script: --- ?php die(var_dump(libxml_disable_entity_loader(false))); Expected result: The default setting (which is true since 5.4.13) should always be var_dump-ed Actual result: -- since this setting is remembered in the thread; after a while all hits return false -- Edit bug report at https://bugs.php.net/bug.php?id=64938edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64938r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64938r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64938r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64938r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64938r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64938r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64938r=needscript Try newer version: https://bugs.php.net/fix.php?id=64938r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64938r=support Expected behavior: https://bugs.php.net/fix.php?id=64938r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64938r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64938r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64938r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64938r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64938r=dst IIS Stability: https://bugs.php.net/fix.php?id=64938r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64938r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64938r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64938r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64938r=mysqlcfg
Bug #64395 [Com]: Wrong result
Edit report at https://bugs.php.net/bug.php?id=64395edit=1 ID: 64395 Comment by: sjon at hortensius dot net Reported by:abc905 at mail dot ru Summary:Wrong result Status: Open Type: Bug Package:Network related Operating System: Windows 7 x64 PHP Version:5.4.13 Block user comment: N Private report: N New Comment: Php interprets numbers with leading zeros as octal [1]. Octal 011 = Decimal 9. Also, I think this is not a valid IP address notation. This is fixed in newer PHP versions, where this format is rejected and false is returned; see http://3v4l.org/EBD9k 1. http://php.net/manual/en/language.types.integer.php Previous Comments: [2013-03-28 15:48:28] abc905 at mail dot ru PHP. Ver. 5.4.13 (Open Server Win7 x64) Output: 1.1.011.011 - 1.1.9.9 1.1.071.071 - 1.1.57.57 1.1.081.081 - 0.0.0.0 Looks like long2ip() converts segments with leading zero as octal. [2013-03-21 16:11:01] abc905 at mail dot ru Unfortunatly my output is wrong PHP. Ver. 5.4.11 (Open Server Win7 x64) and 5.4.9 (Windows Installer install) Output: 1.1.011.011 - 1.1.9.9 1.1.071.071 - 1.1.57.57 1.1.081.081 - 0.0.0.0 Looks like long2ip() converts segments with leading zero as octal. [2013-03-17 02:39:34] pete at petermcdonald dot co dot uk I have tried to reproduce on php 5.4.11 (zend server install) using code specified but output is expected 1.1.11.11. [2013-03-08 19:54:51] abc905 at mail dot ru Description: Hello, It seems ip2long function returns wrong result 1.1.9.9 instead of 1.1.11.11 when convert ip address like '1.1.011.011' Thank you, Alexander --- From manual page: http://www.php.net/function.long2ip --- Test script: --- $ip = '1.1.011.011'; $ip_long = sprintf(%u, ip2long($ip)); print long2ip($ip_long); -- Edit this bug report at https://bugs.php.net/bug.php?id=64395edit=1
Bug #63898 [Com]: json_encode sets string to null for invalid characters
Edit report at https://bugs.php.net/bug.php?id=63898edit=1
ID: 63898
Comment by: Sjon at hortensius dot net
Reported by:sreed at ontraport dot com
Summary:json_encode sets string to null for invalid
characters
Status: Open
Type: Bug
Package:JSON related
Operating System: All
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This actually worked fine in 5.3.14 but was broken in 5.3.14:
http://3v4l.org/Eouni#v5314
5.2.0 - 5.2.6 would truncate the character without notice but wouldn't produce
invalid json either
Previous Comments:
[2013-01-04 01:06:40] sreed at ontraport dot com
.
[2013-01-04 01:04:31] sreed at ontraport dot com
Description:
When you use json_encode with an invalid UTF-8 byte sequence in a string PHP
will
generate a warning (with display_errors set to off) and the function returns an
invalid json encoded string. The string with the invalid UTF-8 byte sequence is
replaced with null (for example: {null:}). This is invalid json and can not
be
decoded with json_decode.
I would think the expected behavior should be that json_encode should never
returns an invalid json encoded string. It should either return false on
failure
as the documentation states or the invalid UTF-8 byte sequence should be
handled
in a way that does not corrupt the json string.
Test script:
---
$key = Foo . chr(163);
$array = array($key = );
var_dump($array);
$json = json_encode($array);
echo $json.\n;
var_dump(json_decode($json));
Expected result:
I would expect the returned json string to be valid or for json_encode to
return
false.
Actual result:
--
array(1) {
[Foo �]=
string(0)
}
{null:}
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63898edit=1
Bug #62536 [Com]: file uploads MAX_FILE_SIZE doesn't work as described
Edit report at https://bugs.php.net/bug.php?id=62536edit=1
ID: 62536
Comment by: Sjon at hortensius dot net
Reported by:danny at tibibi dot com
Summary:file uploads MAX_FILE_SIZE doesn't work as described
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: Windows Server 2008
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
If you read the link I posted, you'll see that PHP _also_ checks for the
defined
MAX_FILE_SIZE and behaves the same as it would with max_upload_size @ini.
So: PHP checks this too, but the client-side advantage isn't implemented in any
browser (which is also described here: https://bugs.php.net/bug.php?id=40387)
Previous Comments:
[2012-07-12 17:15:01] danny at tibibi dot com
Thanks for your comment.
If php doesn't do anything with the variable, then why is it php returns error
2 in the $_FILES array when I set that variable, and upload a file that is
smaller than the max_upload_size in the .ini file but larger than the
MAX_FILE_SIZE variable I post?
[2012-07-12 13:57:07] Sjon at hortensius dot net
This feature is meant for clients (eg. browsers), but it seems your browser
doesn't implement this feature. PHP doesn't do anything with this variable
More info @
http://stackoverflow.com/questions/1381364/max-file-size-in-php-whats-the-point
[2012-07-11 17:10:07] danny at tibibi dot com
Description:
The documentation for handling file uploads,
http://us3.php.net/manual/en/features.file-upload.post-method.php states that
when declaring a hidden field named MAX_FILE_SIZE, if the file submitted is
larger, then the user will not have to wait longer to be told that the file was
too large.
?php
if (isset($_POST['MAX_FILE_SIZE']))
{
echo $_FILES['file1']['error'];
}
?
html
body
form action=/test.php method=post enctype=multipart/form-data
input type=hidden name=MAX_FILE_SIZE value=100 /
input type=file name=file1
input type=submit value=submit
/form
/body
/html
Actual result:
--
The complete file gets uploaded however big it is, and the result shows: 2
This confirms that MAX_FILE_SIZE worked, and the file was too large, but it did
not stop processing the request after 100 bytes were processed.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62536edit=1
Bug #62536 [Com]: file uploads MAX_FILE_SIZE doesn't work as described
Edit report at https://bugs.php.net/bug.php?id=62536edit=1
ID: 62536
Comment by: Sjon at hortensius dot net
Reported by:danny at tibibi dot com
Summary:file uploads MAX_FILE_SIZE doesn't work as described
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: Windows Server 2008
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
This feature is meant for clients (eg. browsers), but it seems your browser
doesn't implement this feature. PHP doesn't do anything with this variable
More info @
http://stackoverflow.com/questions/1381364/max-file-size-in-php-whats-the-point
Previous Comments:
[2012-07-11 17:10:07] danny at tibibi dot com
Description:
The documentation for handling file uploads,
http://us3.php.net/manual/en/features.file-upload.post-method.php states that
when declaring a hidden field named MAX_FILE_SIZE, if the file submitted is
larger, then the user will not have to wait longer to be told that the file was
too large.
?php
if (isset($_POST['MAX_FILE_SIZE']))
{
echo $_FILES['file1']['error'];
}
?
html
body
form action=/test.php method=post enctype=multipart/form-data
input type=hidden name=MAX_FILE_SIZE value=100 /
input type=file name=file1
input type=submit value=submit
/form
/body
/html
Actual result:
--
The complete file gets uploaded however big it is, and the result shows: 2
This confirms that MAX_FILE_SIZE worked, and the file was too large, but it did
not stop processing the request after 100 bytes were processed.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62536edit=1
Bug #62524 [Com]: fopen follows redirects for non-3xx statuses
Edit report at https://bugs.php.net/bug.php?id=62524edit=1
ID: 62524
Comment by: Sjon at hortensius dot net
Reported by:mike dot hall at twistdigital dot co dot uk
Summary:fopen follows redirects for non-3xx statuses
Status: Open
Type: Bug
Package:Streams related
Operating System: Ubuntu 12.04
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
A more complete example confirms this behavior:
I also fixed some syntax errors
?php
header('Location: http://php.net', true, 201);
if (isset($_GET['waa']))
return;
$context = stream_context_create(array(
http = array(
method = POST,
header = Content-Length: 13,
content = {\foo\:\bar\},
),
));
$fp = fopen('http://'.$_SERVER['SERVER_NAME']. $_SERVER['PHP_SELF'] .'?waa=1',
'r', null, $context);
print(stream_get_contents($fp));
Previous Comments:
[2012-07-10 16:00:52] mike dot hall at twistdigital dot co dot uk
Description:
The HTTP location header can either be used to direct the user to another
resource (when accompanied by a 3xx status code) or to inform the user of the
location of the document they just created (with a 2xx) status code.
It doesn't make sense to treat the location header as a redirect in the second
context - the location header indicates a redirect only when accompanied by a
3xx
status code.
Currently, PHP follows Location headers as if they are redirects regardless of
the returned status code.
Test script:
---
$context = stream_context_create([
http = [
method = POST
header = Content-Length: 13
content = {\foo\:\bar\},
],
]);
// Returns HTTP/1.1 201 Created
// Location: http://example.com/mydb/documentid
//
// {status:ok}
$fp = fopen('http://example.com/mydb', 'r', null, $context);
$data = stream_get_contents($fp);
list($headers, $body) = explode(\r\n\r\n, $data, 2);
echo $body;
Expected result:
{status:ok}
Actual result:
--
{foo:bar}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62524edit=1
Bug #62476 [Com]: DateTime::createFromFormat z format incorrect wrt 29.02
Edit report at https://bugs.php.net/bug.php?id=62476edit=1
ID: 62476
Comment by: Sjon at hortensius dot net
Reported by:kaido at tradenet dot ee
Summary:DateTime::createFromFormat z format incorrect wrt
29.02
Status: Open
Type: Bug
Package:Calendar related
Operating System: debian 2.6.32-5-amd64
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I can confirm this, this is broken since 5.3.9
http://3v4l.org/1Z4W4
Previous Comments:
[2012-07-04 00:20:58] kaido at tradenet dot ee
Description:
When creating DateTime object from string and using z (day of year) format
option,
the 29.02 of the leap year is missing. works ok in 5.3.5
Test script:
---
for ($d=55;$d65;$d++) {
$dt = DateTime::createFromFormat ('z.Y', $d.'.2012');
$dd = $dt-format ('d.m.Y');
echo $d $dd\n;
}
29.02.2012 is clearly missing ..
Expected result:
55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 29.02.2012
60 01.03.2012
61 02.03.2012
62 03.03.2012
63 04.03.2012
64 05.03.2012
Actual result:
--
55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 01.03.2012
60 02.03.2012
61 03.03.2012
62 04.03.2012
63 05.03.2012
64 06.03.2012
--
Edit this bug report at https://bugs.php.net/bug.php?id=62476edit=1
Bug #62468 [Com]: SimpleXML memory leak, if circular references are removed by Garbage Collector
Edit report at https://bugs.php.net/bug.php?id=62468edit=1
ID: 62468
Comment by: Sjon at hortensius dot net
Reported by:zerkyn at gmail dot com
Summary:SimpleXML memory leak, if circular references are
removed by Garbage Collector
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Windows 7, Linux
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
I can confirm this, but it has already been fixed in PHP 5.4. I assume this is
because of the circular references that were fixed then.
http://3v4l.org/JICRi
Previous Comments:
[2012-07-02 20:13:45] zerkyn at gmail dot com
Description:
The SimpleXMLElement memory leaks, when:
1) An object holds reference to a SimpleXMLElement, and
2) The object is involved in a circular references net, and
3) All external references to that net are cleared, so Garbage Collector finds
that net, correctly sees it as a garbage cycle, and cleans all its objects
After the Garbage Collector finishes its work, the memory, consumed by
SimpleXMLElement is not freed, thus producing a memory leak.
The issue is reproduced both at Windows and Linux platforms.
Full version for the test script is there:
https://dl.dropbox.com/u/17950262/php/issues/simplexml_memory_leak.zip
Test script:
---
?php
class SelfLinked
{
public $xml;
public $me;
public function __construct()
{
$this-xml = simplexml_load_file('pretty_big_file_of_1mb_size.xml');
$this-me = $this;
}
}
echo Sys memory usage before: , SystemMemoryUsage(), \n;
for ($i = 0; $i 1000; $i++) {
$a = new SelfLinked();
unset($a);
gc_collect_cycles();
}
echo Sys memory usage after: , SystemMemoryUsage(), \n;
/** - */
function SystemMemoryUsage()
{
...
// Return memory consumption by executing system tool - tasklist, ps or
anything else
// See https://bugs.php.net/bug.php?id=62467 on proper memory profiling of
SimpleXML functions
}
}
Expected result:
Memory consumption does not change.
Actual result:
--
Huge increase of memory consumption is reported.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62468edit=1
Bug #62457 [Com]: Excuse me, is this a bug?
Edit report at https://bugs.php.net/bug.php?id=62457edit=1
ID: 62457
Comment by: Sjon at hortensius dot net
Reported by:mybugs at 163 dot com
Summary:Excuse me, is this a bug?
Status: Open
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Microsoft Windows Server 2003 R2
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
What if you remove all '@' from your script, what are the error-messages that
appear? Because with those added, all errors are hidden.
Previous Comments:
[2012-07-01 06:43:48] mybugs at 163 dot com
php.ini
disable_functions =system
[PATH= D:/Web/test.com/public]
open_basedir
[2012-07-01 06:42:05] mybugs at 163 dot com
Description:
php.ini
[PATH= D:/Web/test.com/public]
open_basedir=D:/Web/test.com/public/
Test script:
---
?php
echo 'open_basedir:'.ini_get('open_basedir').'br /'; //D:\WEB\TEST_COM\
$cmd = 'ping qq.com';
echo execute('system',$cmd);
echo execute('passthru',$cmd);
echo execute('shell_exec',$cmd);
echo execute('exec',$cmd);
echo execute('popen',$cmd);
function execute($type,$cfe) {
$data = '';
if ($cfe) {
if($type=='system') {
@ob_start();
@system($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='passthru') {
@ob_start();
@passthru($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='shell_exec') {
$data = @shell_exec($cfe);
} elseif($type=='exec') {
@exec($cfe,$data);
$data = join(\n,$data);
} elseif($type=='popen') {
$f = @popen($cfe,r);
while(!@feof($f)) {
$data .= @fread($f,1024);
}
@pclose($f);
}
}
return $type.'--br /'.$data.'br /'.$type.'--br
/br /';
}
?
Expected result:
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
Pinging qq.com [119.147.15.13] with 32 bytes of data: Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Reply from 119.147.15.13: bytes=32 time=11ms TTL=56
Reply from 119.147.15.13: bytes=32 time=11ms TTL=56 Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Ping statistics for 119.147.15.13: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 11ms, Maximum = 11ms, Average = 11ms
passthru--
shell_exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
shell_exec--
exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
exec--
popen--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
popen--
Actual result:
--
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
passthru--
shell_exec--
shell_exec--
exec--
exec--
popen--
popen--
--
Edit this bug report at https://bugs.php.net/bug.php?id=62457edit=1
Bug #62457 [Com]: Excuse me, is this a bug?
Edit report at https://bugs.php.net/bug.php?id=62457edit=1
ID: 62457
Comment by: Sjon at hortensius dot net
Reported by:mybugs at 163 dot com
Summary:Excuse me, is this a bug?
Status: Open
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Microsoft Windows Server 2003 R2
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Aha, so your report is that open_basedir does not restrict the binaries that
you
can run using the various methods of system-calls? Because that is not a bug :)
open_basedir, by design, cannot limit the paths that system-calls will
eventually
be able to reach since it has no control over that. This was previously
reported
as #55761
Also, the next time you report a bug, a more descriptive title would be
appreciated!
Previous Comments:
[2012-07-01 11:30:20] mybugs at 163 dot com
I 'm sorry . I set the wrong position by Actual result and Expected result
at the time of submission .
It should be theActual resultis the Expected result,and the Expected
result is the Actual result
This problem is that it can restrict path but at the same time it also can
perform the other program except the path.
It is the significant security hidden danger.
fix
php.ini
disable_functions=system
[PATH=D:/Web/test.com/public]
open_basedir=D:/Web/test.com/public/
[2012-07-01 09:58:28] Sjon at hortensius dot net
What if you remove all '@' from your script, what are the error-messages that
appear? Because with those added, all errors are hidden.
[2012-07-01 06:43:48] mybugs at 163 dot com
php.ini
disable_functions =system
[PATH= D:/Web/test.com/public]
open_basedir
[2012-07-01 06:42:05] mybugs at 163 dot com
Description:
php.ini
[PATH= D:/Web/test.com/public]
open_basedir=D:/Web/test.com/public/
Test script:
---
?php
echo 'open_basedir:'.ini_get('open_basedir').'br /'; //D:\WEB\TEST_COM\
$cmd = 'ping qq.com';
echo execute('system',$cmd);
echo execute('passthru',$cmd);
echo execute('shell_exec',$cmd);
echo execute('exec',$cmd);
echo execute('popen',$cmd);
function execute($type,$cfe) {
$data = '';
if ($cfe) {
if($type=='system') {
@ob_start();
@system($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='passthru') {
@ob_start();
@passthru($cfe);
$data = @ob_get_contents();
@ob_end_clean();
} elseif($type=='shell_exec') {
$data = @shell_exec($cfe);
} elseif($type=='exec') {
@exec($cfe,$data);
$data = join(\n,$data);
} elseif($type=='popen') {
$f = @popen($cfe,r);
while(!@feof($f)) {
$data .= @fread($f,1024);
}
@pclose($f);
}
}
return $type.'--br /'.$data.'br /'.$type.'--br
/br /';
}
?
Expected result:
open_basedir:D:\Web\test.com\public\
system--
system--
passthru--
Pinging qq.com [119.147.15.13] with 32 bytes of data: Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Reply from 119.147.15.13: bytes=32 time=11ms TTL=56
Reply from 119.147.15.13: bytes=32 time=11ms TTL=56 Reply from 119.147.15.13:
bytes=32 time=11ms TTL=56 Ping statistics for 119.147.15.13: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 11ms, Maximum = 11ms, Average = 11ms
passthru--
shell_exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss), Approximate round trip times in
milli-seconds: Minimum = 9ms, Maximum = 9ms, Average = 9ms
shell_exec--
exec--
Pinging qq.com [119.147.15.17] with 32 bytes of data: Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Reply from 119.147.15.17: bytes=32 time=9ms TTL=56
Reply from 119.147.15.17: bytes=32 time=9ms TTL=56 Reply from 119.147.15.17:
bytes=32 time=9ms TTL=56 Ping statistics for 119.147.15.17: Packets: Sent = 4,
Received
Bug #62456 [Com]: Incorrect description of notice
Edit report at https://bugs.php.net/bug.php?id=62456edit=1
ID: 62456
Comment by: Sjon at hortensius dot net
Reported by:iblacksmoke at gmail dot com
Summary:Incorrect description of notice
Status: Open
Type: Bug
Package:I18N and L10N related
Operating System: debian linux
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
If you suspect that this is caused by encoding in your script, can't you post
an
example that actually contains these characters? Because your current
test-script
works fine here.
Maybe you can post an example with eval and chr?
Previous Comments:
[2012-06-30 22:57:59] iblacksmoke at gmail dot com
Description:
Description of notice when calling missing property of standard php object
contains incorrect characters (possibly from different encoding). They cause
error in class of standard class ErrorException, and script returns fatal
error(with no information) rather than exception. It turns out there as much as
two bugs: incorrect encoding of strings and lack of data filtering in
ErrorException constructor.
Test script:
---
one:
$test = new StdClass();
echo $test-qwerty;
two:
set_error_handler(function($errno, $errstr, $errfile, $errline){
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});
$test = new StdClass();
echo $test-qwerty;
Expected result:
one:
Notice: Undefined property: stdClass::$qwerty in script
two:
correct php exception
Actual result:
--
one:
Notice: Undefined property: stdClass�K� ::$qwerty in script
two:
Fatal error: in script
--
Edit this bug report at https://bugs.php.net/bug.php?id=62456edit=1
Bug #62437 [Com]: Strange behavior with global variables (objects) in ob_start() output callback
Edit report at https://bugs.php.net/bug.php?id=62437edit=1
ID: 62437
Comment by: Sjon at hortensius dot net
Reported by:tero dot tasanen at gmail dot com
Summary:Strange behavior with global variables (objects) in
ob_start() output callback
Status: Open
Type: Bug
Package:Output Control
Operating System: Linux 64bit
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
Contrary to what tony2001 says in #40604, this was actually working fine until
it
was broken in 5.2
http://3v4l.org/SUUkK
The reason that http://3v4l.org/pZ2PP works might be explained to the second
reference to the same object which could prevent destruction, but that would
then
actually be a bug too (since it indicates a memory-leak).
Previous Comments:
[2012-06-28 11:56:12] tero dot tasanen at gmail dot com
Description:
Global variables in output buffering seem to work in very strange way. don't
know
actually if this has anything to do with output buffering callback but see the
test case attached to reproduce this.
And the strangest thing is that if you uncomment the last line the script works
as expected!
After some searching I found two similar bug reports (#40604, #44840) and the
comments indicate that this is expected behavior?! Not just that it seem really
strange that all objects get destroyed before the output callback is called,
but
why does the use of the $test variable in the end of the script change this
behavior? This really does not make any sense!
Test script:
---
?
function output($buffer) {
global $object;
return $buffer . $object-bar;
}
ob_start('output');
$object = new stdClass();
$object-bar = bar;
echo foo ;
// $test = $object;
Expected result:
foo bar
Actual result:
--
PHP Notice: Trying to get property of non-object in /home/ttasanen/test.php on
line 5
PHP Stack trace:
PHP 1. output() /home/ttasanen/test.php:0
foo
--
Edit this bug report at https://bugs.php.net/bug.php?id=62437edit=1
Bug #62419 [Com]: RuntimeException throws fatal error if passing a previous exception to the ctor
Edit report at https://bugs.php.net/bug.php?id=62419edit=1 ID: 62419 Comment by: Sjon at hortensius dot net Reported by:bugs dot php at mohiva dot com Summary:RuntimeException throws fatal error if passing a previous exception to the ctor Status: Open Type: Bug Package:SPL related Operating System: Gentoo Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I cannot reproduce this, it seems to work fine? http://3v4l.org/IAF3d#v530 Previous Comments: [2012-06-26 11:26:52] bugs dot php at mohiva dot com Description: If you pass a previous exception to the constructor of the RuntimeException class, then PHP throws a fatal error without an error message. I have tested those exceptions which are derived from RuntimeException, and they all work fine. The same counts for the base Exception class. Test script: --- ?php throw new RuntimeException(Exception message, 0, new Exception()); Expected result: Fatal error: Uncaught exception 'RuntimeException' ... on line 3 Actual result: -- Fatal error: in exception.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=62419edit=1
Bug #62189 [Com]: Behavior of serialize has changed
Edit report at https://bugs.php.net/bug.php?id=62189edit=1 ID: 62189 Comment by: Sjon at hortensius dot net Reported by:mg at ovos dot at Summary:Behavior of serialize has changed Status: Open Type: Bug Package:Variables related Operating System: Win64 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Maybe you misread my comment, or misinterpreted the results demonstrated. I can reproduce your described behavior perfectly using the script I posted. In the results I posted, 5.4 references only Placeholder#8 and #10, while 5.3 and earlier contains references to Placeholder#8, #10, #12 and #14; demonstrating what was fixed in 5.4 again, this behaviour is better in 5.4 and there is no bug demonstrated in that script Previous Comments: [2012-06-23 21:13:52] mg at ovos dot at Dear Sjon, You stripped it from the key lines, no wonder you cannot reproduce it. It is all about the lines that you removed. Cheers, Marcin [2012-06-23 14:25:15] Sjon at hortensius dot net Have a look at this example (based on your code): http://3v4l.org/D7HIa Before 5.4, the Placeholder instances were actually different objects. This was fixed in 5.4, therefore the properties correctly reference to the same objects. Regarding your bug, where objects are NOT properly recreated, I am afraid you will need to create an actual reproducable testcase before expecting anyone to take a look at it :) [2012-06-12 12:45:06] mg at ovos dot at Feedback - Open. [2012-06-04 14:09:11] mg at ovos dot at Please have a look at the following scenario: http://pastebin.com/QRWtX0dM Of course such double serialization makes no sense, but I found it to be present in Doctrine 1.2 library. Therefore I am wondering if the references should still work in this case like it was in PHP 5.3. [2012-05-30 17:22:12] mg at ovos dot at It seems that my issue is directly related to fixing a bug in PHP: https://bugs.php.net/bug.php?id=36424 If this is true, the test case I included does not cover entirely the issue I am having. In my case unserialize() does not bring back the referenced object, although the test case does. I had no luck in extracting my scenario into a test case as yet. I am trying to find the difference between test case and the live case, which is obviosly many times more complex. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62189 -- Edit this bug report at https://bugs.php.net/bug.php?id=62189edit=1
Bug #62189 [Com]: Behavior of serialize has changed
Edit report at https://bugs.php.net/bug.php?id=62189edit=1 ID: 62189 Comment by: Sjon at hortensius dot net Reported by:mg at ovos dot at Summary:Behavior of serialize has changed Status: Open Type: Bug Package:Variables related Operating System: Win64 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: Have a look at this example (based on your code): http://3v4l.org/D7HIa Before 5.4, the Placeholder instances were actually different objects. This was fixed in 5.4, therefore the properties correctly reference to the same objects. Regarding your bug, where objects are NOT properly recreated, I am afraid you will need to create an actual reproducable testcase before expecting anyone to take a look at it :) Previous Comments: [2012-06-12 12:45:06] mg at ovos dot at Feedback - Open. [2012-06-04 14:09:11] mg at ovos dot at Please have a look at the following scenario: http://pastebin.com/QRWtX0dM Of course such double serialization makes no sense, but I found it to be present in Doctrine 1.2 library. Therefore I am wondering if the references should still work in this case like it was in PHP 5.3. [2012-05-30 17:22:12] mg at ovos dot at It seems that my issue is directly related to fixing a bug in PHP: https://bugs.php.net/bug.php?id=36424 If this is true, the test case I included does not cover entirely the issue I am having. In my case unserialize() does not bring back the referenced object, although the test case does. I had no luck in extracting my scenario into a test case as yet. I am trying to find the difference between test case and the live case, which is obviosly many times more complex. [2012-05-30 13:26:14] mg at ovos dot at I'm attaching a DIFF with output of the testCase: http://diffchecker.com/5399UzhN Left side: PHP 5.3.8 Right side: PHP 5.4.3 [2012-05-30 13:20:48] mg at ovos dot at Hello! I managed to produce a simple testCase, please find it here: http://pastebin.com/sw1ZwvNv The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62189 -- Edit this bug report at https://bugs.php.net/bug.php?id=62189edit=1
Bug #62333 [Nab]: Cannot statically call method to parent class
Edit report at https://bugs.php.net/bug.php?id=62333edit=1
ID: 62333
User updated by:Sjon at hortensius dot net
Reported by:Sjon at hortensius dot net
Summary:Cannot statically call method to parent class
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
You describe my exact problem, but why deny this is a bug? I understand this
would be unfixable without breaking implementations that depend on this
behaviour, but I do not understand that you deny the huge inconsistency, thus
preferably fixable behaviour that PHP has here?
Previous Comments:
[2012-06-19 08:32:13] cataphr...@php.net
Not a bug. A::foo() is not necessarily a static call. Namely, if foo() is not
static and there is a compatible context ($this exists and its class is either
the class of the target method or a subclass of it), an instance call will be
made. In your case, because you sort of have a static and non-static foo() via
magic, the non-static is preferred. You'll have to be creative, like maybe
calling __callstatic directly or using a closure.
[2012-06-15 11:11:53] Sjon at hortensius dot net
Description:
All static calls to a class-parent end up being non-static
Inconsistency clearly proven:
http://3v4l.org/Mkn0L
http://3v4l.org/1L3Wk (same, but without __call)
Test script:
---
See http://3v4l.org/Mkn0L
?php
class A
{
public function __call($name, $args)
{
echo Not static\n;
}
public static function __callStatic($name, $args)
{
echo Static\n;
}
}
class B extends A
{
public function test()
{
forward_static_call(array('A', 'stuff'));
call_user_func(array('A', 'stuff'));
A::stuff();
}
}
class C
{
public function test()
{
forward_static_call(array('A', 'stuff'));
call_user_func(array('A', 'stuff'));
A::stuff();
}
}
A::test();
echo = B =\n;
$b = new B();
$b-test();
echo = C =\n;
$c = new C();
$c-test();
Expected result:
Static
= B =
Not static
Not static
Not static
= C =
Static
Static
Static
Actual result:
--
Static
= B =
Not static
Not static
Not static
= C =
Static
Static
Static
--
Edit this bug report at https://bugs.php.net/bug.php?id=62333edit=1
Bug #62330 [Com]: PHP confuse __callStatic with __call
Edit report at https://bugs.php.net/bug.php?id=62330edit=1
ID: 62330
Comment by: Sjon at hortensius dot net
Reported by:magike dot net at gmail dot com
Summary:PHP confuse __callStatic with __call
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu Server 12.04
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
This is actually a feature: when you use CLASSNAME:: while extending that
class,
it mimics parent::, but to a specific class (so you can skip one parent)
You should instead use forward_static_call for this
Previous Comments:
[2012-06-15 02:40:29] magike dot net at gmail dot com
Description:
I find PHP will call __call instead of __callStatic when I'm calling a non-
exists static method from the class (Class A) which is the parent of current
class
(Class B).
And if the class (Class C) is not the child of that class (Class A), the result
will be correct.
Test script:
---
?php
class A
{
public function __call($name, $args)
{
echo NO\n;
}
public static function __callStatic($name, $args)
{
echo YES\n;
}
}
class B extends A
{
public function test()
{
A::test();
}
}
class C
{
public function test()
{
A::test();
}
}
A::test();
$b = new B();
$b-test();
$c = new C();
$c-text();
Expected result:
YES
YES
YES
Actual result:
--
YES
NO
YES
--
Edit this bug report at https://bugs.php.net/bug.php?id=62330edit=1
[PHP-BUG] Bug #62333 [NEW]: Cannot statically call method to parent class
From: Sjon at hortensius dot net
Operating system:
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Cannot statically call method to parent class
Description:
All static calls to a class-parent end up being non-static
Inconsistency clearly proven:
http://3v4l.org/Mkn0L
http://3v4l.org/1L3Wk (same, but without __call)
Test script:
---
See http://3v4l.org/Mkn0L
?php
class A
{
public function __call($name, $args)
{
echo Not static\n;
}
public static function __callStatic($name, $args)
{
echo Static\n;
}
}
class B extends A
{
public function test()
{
forward_static_call(array('A', 'stuff'));
call_user_func(array('A', 'stuff'));
A::stuff();
}
}
class C
{
public function test()
{
forward_static_call(array('A', 'stuff'));
call_user_func(array('A', 'stuff'));
A::stuff();
}
}
A::test();
echo = B =\n;
$b = new B();
$b-test();
echo = C =\n;
$c = new C();
$c-test();
Expected result:
Static
= B =
Not static
Not static
Not static
= C =
Static
Static
Static
Actual result:
--
Static
= B =
Not static
Not static
Not static
= C =
Static
Static
Static
--
Edit bug report at https://bugs.php.net/bug.php?id=62333edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62333r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62333r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62333r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62333r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62333r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62333r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62333r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62333r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62333r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62333r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62333r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62333r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62333r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62333r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62333r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62333r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62333r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62333r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62333r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62333r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62333r=mysqlcfg
Bug #62330 [Com]: PHP confuse __callStatic with __call
Edit report at https://bugs.php.net/bug.php?id=62330edit=1
ID: 62330
Comment by: Sjon at hortensius dot net
Reported by:magike dot net at gmail dot com
Summary:PHP confuse __callStatic with __call
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu Server 12.04
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
I actually found a related bug, I filed it here:
https://bugs.php.net/bug.php?id=62333
PS. there is a small typo in your script, your last call to -text() should
have
gone to -test()
Previous Comments:
[2012-06-15 10:46:13] Sjon at hortensius dot net
This is actually a feature: when you use CLASSNAME:: while extending that
class,
it mimics parent::, but to a specific class (so you can skip one parent)
You should instead use forward_static_call for this
[2012-06-15 02:40:29] magike dot net at gmail dot com
Description:
I find PHP will call __call instead of __callStatic when I'm calling a non-
exists static method from the class (Class A) which is the parent of current
class
(Class B).
And if the class (Class C) is not the child of that class (Class A), the result
will be correct.
Test script:
---
?php
class A
{
public function __call($name, $args)
{
echo NO\n;
}
public static function __callStatic($name, $args)
{
echo YES\n;
}
}
class B extends A
{
public function test()
{
A::test();
}
}
class C
{
public function test()
{
A::test();
}
}
A::test();
$b = new B();
$b-test();
$c = new C();
$c-text();
Expected result:
YES
YES
YES
Actual result:
--
YES
NO
YES
--
Edit this bug report at https://bugs.php.net/bug.php?id=62330edit=1
Bug #62236 [Com]: Hardcoded path /usr/local/bin/php
Edit report at https://bugs.php.net/bug.php?id=62236edit=1 ID: 62236 Comment by: Sjon at hortensius dot net Reported by:max dot antonoff at gmail dot com Summary:Hardcoded path /usr/local/bin/php Status: Open Type: Bug Package:CGI/CLI related Operating System: Linux PHP Version:5.4.4RC2 Block user comment: N Private report: N New Comment: /usr/bin/pear is a simple script that determines which PHP binary to use. It should be easy to debug this yourself, I think an incorrect $PHP_PEAR_PHP_BIN might cause this for example Previous Comments: [2012-06-05 20:04:05] max dot antonoff at gmail dot com Description: max 23:58:24 php-src $ pear list-all exec: 28: /usr/local/bin/php: not found max 23:58:15 php-src $ php -v PHP 5.4.4-RC2 (cli) (built: Jun 5 2012 23:48:00) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies max 23:58:29 php-src $ which php ; which pear; php -i |grep configure /home/max/local/bin/php /home/max/local/bin/pear Configure Command = './configure' '--prefix=/home/max/local' '--enable-proxy' '--disable-cgi' '--with-mysqli' '--enable-fpm' '--with-fpm-user=max' '--with- fpm-group=max' '--with-config-file-path=/home/max/local/etc/php.ini' '--with- config-file-scan-dir=/home/max/local/etc/php.d' '--enable-sigchild' '--disable- ipv6' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath' '-- with-bz2' '--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp' '-- with-gd' '--enable-gd-native-ttf' '--with-mhash' '--enable-mbstring' '--with- mcrypt' '--with-mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '-- enable-pcntl' '--with-pdo-mysql' '--enable-shmop' '--enable-soap' '--enable- sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable- wddx' '--with-xsl' '--enable-zip' '--enable-mysqlnd' '--with- pear=/home/max/local/PEAR' '--with-jpeg-dir' '--with-png-dir' '--enable-intl' Test script: --- max 23:58:24 php-src $ pear list-all Expected result: list of packages Actual result: -- exec: 28: /usr/local/bin/php: not found -- Edit this bug report at https://bugs.php.net/bug.php?id=62236edit=1
Bug #62264 [Com]: array_walk not changeing keys
Edit report at https://bugs.php.net/bug.php?id=62264edit=1
ID: 62264
Comment by: Sjon at hortensius dot net
Reported by:marti dot markov at gmail dot com
Summary:array_walk not changeing keys
Status: Open
Type: Bug
Package:Arrays related
Operating System: Mac OS X
PHP Version:master-Git-2012-06-08 (Git)
Block user comment: N
Private report: N
New Comment:
The manual says Only the values of the array may potentially be changed;
If
the callback does not respect this requirement, the behavior of this function
is
undefined, and unpredictable.
I think this could be a feature request, but not really a bug?
Also, your test-script is incomplete; but PHP's behavious is pretty consistent
regarding this functionality: http://3v4l.org/1dn4f
Previous Comments:
[2012-06-08 09:32:25] marti dot markov at gmail dot com
Description:
I have found this problem with 5.3.10 and got the latest GIT head revision and
the problem was still there.
When I try and change the value of the key it will not update it in the array,
even though that I use the key as a reference.
Test script:
---
$array = ( 'a' = 'Hello', 'b' = 'World');
array_walk($array, 'adda');
function adda($value, $key) {
$key = a.$key;
}
Expected result:
$array = ( 'aa' = 'Hello', 'ab' = 'World');
Actual result:
--
$array = ( 'a' = 'Hello', 'b' = 'World');
--
Edit this bug report at https://bugs.php.net/bug.php?id=62264edit=1
Bug #62253 [Com]: Number check bug
Edit report at https://bugs.php.net/bug.php?id=62253edit=1
ID: 62253
Comment by: Sjon at hortensius dot net
Reported by:rophp at live dot it
Summary:Number check bug
Status: Open
Type: Bug
Package:*Math Functions
Operating System: All
PHP Version:Irrilevante
Block user comment: N
Private report: N
New Comment:
You should have a look at bug number #43304
Previous Comments:
[2012-06-07 17:57:56] rophp at live dot it
Description:
Hello, when i go to check if the 2 vars are equals with this return 'equal'
also if the end number is different. There is a limit?
Test script:
---
$record['xod']=727202440420867488;
$cookiecodiceconnessione=727202440420867484;
if ($record['xod']==$cookiecodiceconnessione)
{
echo 'equal';
}else{
echo 'not equal';
}
Expected result:
not equal
Actual result:
--
equal
--
Edit this bug report at https://bugs.php.net/bug.php?id=62253edit=1
Bug #62181 [Com]: wddx_serialize_value() returns wrong string
Edit report at https://bugs.php.net/bug.php?id=62181edit=1 ID: 62181 Comment by: sjon at hortensius dot net Reported by:clemens at gutweiler dot net Summary:wddx_serialize_value() returns wrong string Status: Open Type: Bug Package:WDDX related Operating System: Linux PHP Version:5.4.3 Block user comment: N Private report: N New Comment: I cannot reproduce this bug using a vanilla 5.4.3 version, could you check if disabling your extensions fixes this? http://3v4l.org/nH7LO Previous Comments: [2012-05-29 11:05:34] clemens at gutweiler dot net Description: wddx_serialize_value() returns wrong string, associative key elements are wrong interpreted in the output the resulting string could not be interpreted by wddx_deserialize() Test script: --- var_dump(wddx_serialize_value(array(foo=1))); PHP 5.3.8 string(118) wddxPacket version='1.0'header/datastructvar name='foo'number1/number/var/struct/data/wddxPacket PHP 5.4.3 string(117) wddxPacket version='1.0'header/datastructvar name='foo'number1/number/var/array/data/wddxPacket var_dump(wddx_serialize_value(array(foo=1,bar=barstr))); PHP 5.3.8 string(163) wddxPacket version='1.0'header/datastructvar name='foo'number1/number/varvar name='bar'stringbarstr/string/var/struct/data/wddxPacket PHP 5.4.3 string(140) wddxPacket version='1.0'header/datastructvar name='foo'number1/number/varstringbarstr/string/array/data/wddxPacket -- Edit this bug report at https://bugs.php.net/bug.php?id=62181edit=1
Req #61972 [Com]: addchild treats text as a tag
Edit report at https://bugs.php.net/bug.php?id=61972edit=1 ID: 61972 Comment by: sjon at hortensius dot net Reported by:crashyn at op dot pl Summary:addchild treats text as a tag Status: Open Type: Feature/Change Request Package:SimpleXML related Operating System: Windows XP PHP Version:5.4.2 Block user comment: N Private report: N New Comment: Shouldn't the values passed to xmlNewChild in addChild go through BAD_CAST like all other Xml related methods do? Previous Comments: [2012-05-20 21:54:40] crashyn at op dot pl ?php $xml_header = ?xml version='1.0' encoding='utf-8'?xml/; $xml = new SimpleXMLElement($xml_header); $xml-addChild(first_string,this is lt;mystringgt;); $xml-addChild(second_string,this is lt; mystringgt;); $xml-asXML(test.xml); echo pre . $xml-first_string . br /; // 'this is ' echo $xml-second_string . /pre;// 'this is mystring' ? [2012-05-16 20:55:00] riptide dot tempora at opinehub dot com Can you provide a test script and its actual vs. expected output to show exactly what you mean? [2012-05-07 21:09:58] crashyn at op dot pl Description: --- From manual page: http://www.php.net/simplexmlelement.addchild --- addChild treats lt;my_stringgt; as a tag nd removes it completely -- Edit this bug report at https://bugs.php.net/bug.php?id=61972edit=1
[PHP-BUG] Bug #62135 [NEW]: Closure-bindTo plus $this reassign = corruption
From: Sjon at hortensius dot net
Operating system: ArchLinux
PHP version: 5.4.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Closure-bindTo plus $this reassign = corruption
Description:
I just found the bindTo method on a Closure, a started to play with it. I
found
out I can get some serieusly strange behaviour by re-assigning $this.
Somehow I
end up with one variable pointing to different objects?
Test script:
---
From: http://3v4l.org/bp598#v540
?php
class A
{
public $a = 'public';
}
$m = function (){
$x = $this;
$x = new stdClass;
var_dump($this, $this-a);
};
$a = new A;
$m = $m-bindTo($a);
$m();
Expected result:
* Cannot re-assign $this OR
* 'stdClass' + Notice OR
* 'A' + 'public
Actual result:
--
object(stdClass)#1 (0) {
}
string(6) public
--
Edit bug report at https://bugs.php.net/bug.php?id=62135edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62135r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62135r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62135r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62135r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62135r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62135r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62135r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62135r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62135r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62135r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62135r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62135r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62135r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62135r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62135r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62135r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62135r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62135r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62135r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62135r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62135r=mysqlcfg
Bug #62135 [Nab]: Closure-bindTo plus $this reassign = corruption
Edit report at https://bugs.php.net/bug.php?id=62135edit=1
ID: 62135
User updated by:Sjon at hortensius dot net
Reported by:Sjon at hortensius dot net
Summary:Closure-bindTo plus $this reassign = corruption
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: ArchLinux
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
Ah, too bad; I should have tested that. Thanks for your explanation!
Previous Comments:
[2012-05-24 10:02:50] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
With the can not reassign $this message we try to prevent mistakes. For
performance and architecture reasons we can't prevent all ways one can shoot in
one own's foot though. your behavior also isn't closure related:
class A {
public$a = public;
function __construct() {
$x = $this;
$x = new stdClass;
var_dump($this, $this-a);
}
}
new A();
will show the same result. The difference between $this and $this-a comes from
the fact that $this is some magic variable.
[2012-05-24 09:25:58] Sjon at hortensius dot net
Description:
I just found the bindTo method on a Closure, a started to play with it. I found
out I can get some serieusly strange behaviour by re-assigning $this. Somehow I
end up with one variable pointing to different objects?
Test script:
---
From: http://3v4l.org/bp598#v540
?php
class A
{
public $a = 'public';
}
$m = function (){
$x = $this;
$x = new stdClass;
var_dump($this, $this-a);
};
$a = new A;
$m = $m-bindTo($a);
$m();
Expected result:
* Cannot re-assign $this OR
* 'stdClass' + Notice OR
* 'A' + 'public
Actual result:
--
object(stdClass)#1 (0) {
}
string(6) public
--
Edit this bug report at https://bugs.php.net/bug.php?id=62135edit=1
[PHP-BUG] Bug #61542 [NEW]: xml_parse with invalid attribute returns 1; while xmlwf throws an error
From:
Operating system: Archlinux
PHP version: 5.3.10
Package: XML related
Bug Type: Bug
Bug description:xml_parse with invalid attribute returns 1; while xmlwf throws
an error
Description:
Html with an invalid attribute should make xml_parse return 0, instead of
1
For as far as I can see, xml_* is based on expat. Expat supplies xmlwf, so
I
confirmed checked what xmlwf would return for the xml. I found that xmlwf
behaves
correctly.
--
[sjon@sjon-desktop ~]$ xmlwf
?xml version=1.0 encoding=UTF-8 ?
img src=http://i.mg/; title=a\b /
STDIN:2:34: not well-formed (invalid token)
Test script:
---
$p = xml_parser_create('UTF-8');
$html = 'img src=http://i.mg/; title=a\b /';
var_dump(xml_parse($p, $html));
Expected result:
0
Actual result:
--
1
--
Edit bug report at https://bugs.php.net/bug.php?id=61542edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61542r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61542r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61542r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61542r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61542r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61542r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61542r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61542r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61542r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61542r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61542r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61542r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61542r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61542r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61542r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61542r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61542r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61542r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61542r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61542r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61542r=mysqlcfg
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: sjon at hortensius dot net
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:
@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.
Previous Comments:
[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 (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
Bug #60457 [Com]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457edit=1 ID: 60457 Comment by: sjon at hortensius dot net Reported by:Sjon at hortensius dot net Summary:gc_zval_possible_root SIGSEGV Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: This bug has been solved in a more specific bug which includes a patch: https://bugs.php.net/bug.php?id=60701 Previous Comments: [2012-01-04 08:26:51] Sjon at hortensius dot net For anyone interested, this bug is not related to a single class, but we have worked around, and seen this bug occur again, in many different places. I have also been reproducing this in 5.3.6 / 5.3.5 / 5.3.4 and 5.3.3 [2012-01-04 07:31:07] no at snaxor dot com I may be bumping into this one as well, Similarly, I cannot provide a script to reproduce it since it happens in a project with many classes, but I'll see if I can narrow it down and create one. It is very inconsistent. It will die one the same page but with different data it will be fine. What seems to be sparking it in my case is Smarty, with lots of sub-template files. The content is rendered correctly, but during Smarty's cleanup is when it dies. It is trigger-able via php command line or apache module. gc_disable() doesn't unfortunately have any effect. PHP Version: 5.3.8 on OSX. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x003dca9fd2f1 0x000100359618 in gc_zval_possible_root () (gdb) bt #0 0x000100359618 in gc_zval_possible_root () #1 0x00010034a765 in zend_hash_destroy () #2 0x00010035c86c in zend_object_std_dtor () #3 0x00010035c4f8 in zend_objects_free_object_storage () #4 0x00010035faae in zend_objects_store_del_ref_by_handle_ex () #5 0x00010035fb64 in zend_objects_store_del_ref () #6 0x000100334e2d in _zval_ptr_dtor () #7 0x00010034a765 in zend_hash_destroy () #8 0x00010033f1b0 in _zval_dtor_func () #9 0x000100334e2d in _zval_ptr_dtor () #10 0x00010034a765 in zend_hash_destroy () #11 0x00010035c86c in zend_object_std_dtor () #12 0x00010035c4f8 in zend_objects_free_object_storage () #13 0x00010035f6eb in zend_objects_store_free_object_storage () #14 0x000100337750 in shutdown_executor () #15 0x00010033feae in zend_deactivate () #16 0x0001002f08b1 in php_request_shutdown () #17 0x0001003ba366 in main () #18 0x000110ec in start () [2011-12-12 15:58:33] Sjon at hortensius dot net I am afraid not, gc_disable() doesn't solve this segfault unfortunately [2011-12-11 19:41:22] arekm at maven dot pl Isn't this something similar to last comments of #40479 (there is reproduction script there). [2011-12-07 14:05:33] Sjon at hortensius dot net Description: Our application segfaults after completely finishing the request. Unfortunately I cannot provide a script to reproduce this as it occurs in an application consisting of many classes. I have been poking at this with gdb for a while, but can't find the cause for this problem. How can I supply you with the information you need to resolve this? We can 'fix' the problem by die()-ing in the __destruct of the class that seems to cause this Actual result: -- #0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at /usr/src/debug/php-5.3.8/Zend/zend_gc.c:143 #1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at /usr/src/debug/php-5.3.8/Zend/zend_hash.c:529 #2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:45 #3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:126 #4 0x005c46d6 in zend_objects_store_free_object_storage (objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92 #5 0x00595757 in shutdown_executor () at /usr/src/debug/php- 5.3.8/Zend/zend_execute_API.c:304 #6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php- 5.3.8/Zend/zend.c:891 #7 0x0054f2ce in php_request_shutdown (dummy=value optimized out) at /usr/src/debug/php-5.3.8/main/main.c:1640 #8 0x0062b10f in main (argc=3, argv=0x7fffea88) at /usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363 (gdb) frame 2 #2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:45 45
Bug #60701 [Com]: __toString() which stores $this reference triggers segfault
Edit report at https://bugs.php.net/bug.php?id=60701edit=1
ID: 60701
Comment by: sjon at hortensius dot net
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault
Status: Open
Type: Bug
Package:Class/Object related
Operating System: CentOS
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug is not reproducible when php is compiled with enable-debug. It is
however reproducible in other PHP versions, such as 5.3.7/5.3.6/5.3.5
Previous Comments:
[2012-01-10 16:43:17] daan at react dot com
Description:
A simple object construction where a __toString() stores $this, will trigger a
segfault during garbage collection at the end of the request.
Probably related bug: https://bugs.php.net/bug.php?id=60598
Is a distilled version of this bug: https://bugs.php.net/bug.php?id=60457
Test script:
---
?php
class Container
{
public function getObject()
{
$this-object = new StringableObject();
return $this-object;
}
// This destructor is required to exist to trigger the segfault
public function __destruct()
{
}
}
class StringableObject
{
public function __toString()
{
$this-test = $this;
return '';
}
}
$container = new Container();
$object = $container-getObject();
// Any kind of function which triggers a 'to string' object conversion
// Casting $object with (string) will circumvent the problem
echo trim($object);
// Another call is required to corrupt heap
echo trim('test');
Expected result:
test
Actual result:
--
Segfault
gdb backtrace (with commandline PHP with build tag ZEND_DEBUG_OBJECTS)
[Thread debugging using libthread_db enabled]
Allocated object id #1
Allocated object id #2
Increased refcount of object id #2
Decreased refcount of object id #2
testIncreased refcount of object id #1
Decreased refcount of object id #1
Deallocated object id #1
Program received signal SIGSEGV, Segmentation fault.
0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_gc.c:143
143GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x006d6029 in zend_objects_free_object_storage (object=0x1023dc8)
at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x006da037 in zend_objects_store_del_ref_by_handle_ex (handle=2,
handlers=optimized out) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_objects_API.c:220
#5 0x006da053 in zend_objects_store_del_ref (zobject=0x1022350) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:172
#6 0x006a9571 in _zval_dtor (zvalue=0x1022350) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_variables.h:35
#7 _zval_ptr_dtor (zval_ptr=optimized out) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:447
#8 0x006c3645 in zend_hash_apply_deleter (ht=0xe33188, p=0x1026728) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_hash.c:612
#9 0x006c4f81 in zend_hash_reverse_apply (ht=0xe33188,
apply_func=0x6a9430 zval_call_destructor) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_hash.c:762
#10 0x006a9921 in shutdown_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:226
#11 0x006b7747 in zend_call_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend.c:875
#12 0x006651fd in php_request_shutdown (dummy=optimized out) at
/home/sjon/php-debug/php-5.3.8/main/main.c:1594
#13 0x0042d105 in main (argc=2, argv=0x7fffebb8) at /home/sjon/php-
debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
45zend_hash_destroy(object-properties);
(gdb) print object-ce-name
$1 = 0x1025af0 StringableObject
(gdb) frame 1
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
529ht-pDestructor(q-pData);
(gdb) print_ht ht
[0x010266d0] {
test\0 = [0x01023e40] (refcount=-1) object
Program received signal SIGSEGV, Segmentation fault.
0x006da0a4 in zend_object_store_get_object (zobject=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:272
272return EG(objects_store).object_buckets[handle
Bug #60457 [Opn]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457edit=1
ID: 60457
User updated by:Sjon at hortensius dot net
Reported by:Sjon at hortensius dot net
Summary:gc_zval_possible_root SIGSEGV
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
For anyone interested, this bug is not related to a single class, but we have
worked around, and seen this bug occur again, in many different places.
I have also been reproducing this in 5.3.6 / 5.3.5 / 5.3.4 and 5.3.3
Previous Comments:
[2012-01-04 07:31:07] no at snaxor dot com
I may be bumping into this one as well, Similarly, I cannot provide a script to
reproduce it since it happens in a project with many classes, but I'll see if I
can narrow it down and create one.
It is very inconsistent. It will die one the same page but with different data
it will be fine. What seems to be sparking it in my case is Smarty, with lots
of
sub-template files. The content is rendered correctly, but during Smarty's
cleanup is when it dies.
It is trigger-able via php command line or apache module.
gc_disable() doesn't unfortunately have any effect.
PHP Version: 5.3.8 on OSX.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x003dca9fd2f1
0x000100359618 in gc_zval_possible_root ()
(gdb) bt
#0 0x000100359618 in gc_zval_possible_root ()
#1 0x00010034a765 in zend_hash_destroy ()
#2 0x00010035c86c in zend_object_std_dtor ()
#3 0x00010035c4f8 in zend_objects_free_object_storage ()
#4 0x00010035faae in zend_objects_store_del_ref_by_handle_ex ()
#5 0x00010035fb64 in zend_objects_store_del_ref ()
#6 0x000100334e2d in _zval_ptr_dtor ()
#7 0x00010034a765 in zend_hash_destroy ()
#8 0x00010033f1b0 in _zval_dtor_func ()
#9 0x000100334e2d in _zval_ptr_dtor ()
#10 0x00010034a765 in zend_hash_destroy ()
#11 0x00010035c86c in zend_object_std_dtor ()
#12 0x00010035c4f8 in zend_objects_free_object_storage ()
#13 0x00010035f6eb in zend_objects_store_free_object_storage ()
#14 0x000100337750 in shutdown_executor ()
#15 0x00010033feae in zend_deactivate ()
#16 0x0001002f08b1 in php_request_shutdown ()
#17 0x0001003ba366 in main ()
#18 0x000110ec in start ()
[2011-12-12 15:58:33] Sjon at hortensius dot net
I am afraid not, gc_disable() doesn't solve this segfault unfortunately
[2011-12-11 19:41:22] arekm at maven dot pl
Isn't this something similar to last comments of #40479 (there is
reproduction script there).
[2011-12-07 14:05:33] Sjon at hortensius dot net
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in an
application consisting of many classes. I have been poking at this with gdb for
a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580)
at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=value optimized out) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object-properties);
(gdb) print *object-ce
$1 = {type = 2 '\002', name = 0xcdce30 React_Introspection_Controller,
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001
Bug #60457 [Opn]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457edit=1
ID: 60457
User updated by:Sjon at hortensius dot net
Reported by:Sjon at hortensius dot net
Summary:gc_zval_possible_root SIGSEGV
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I am afraid not, gc_disable() doesn't solve this segfault unfortunately
Previous Comments:
[2011-12-11 19:41:22] arekm at maven dot pl
Isn't this something similar to last comments of #40479 (there is
reproduction script there).
[2011-12-07 14:05:33] Sjon at hortensius dot net
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in an
application consisting of many classes. I have been poking at this with gdb for
a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580)
at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=value optimized out) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object-properties);
(gdb) print *object-ce
$1 = {type = 2 '\002', name = 0xcdce30 React_Introspection_Controller,
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001',
ce_flags = 0, function_table = {nTableSize = 32,
nTableMask = 31, nNumOfElements = 27, nNextFreeElement = 0,
pInternalPointer
= 0xcde7b0, pListHead = 0xcde7b0, pListTail = 0xce9d10, arBuckets = 0xce8fa8,
pDestructor = 0x599450 zend_function_dtor,
persistent = 0 '\000', nApplyCount = 0 '\000', bApplyProtection = 0
'\000'},
default_properties = {nTableSize = 8, nTableMask = 7, nNumOfElements = 5,
nNextFreeElement = 0, pInternalPointer = 0xce74c8,
pListHead = 0xce74c8, pListTail = 0xce7660, arBuckets = 0xcdcf50,
pDestructor = 0x595420 _zval_ptr_dtor, persistent = 0 '\000', nApplyCount = 0
'\000', bApplyProtection = 0 '\000'}, properties_info = {
nTableSize = 8, nTableMask = 7, nNumOfElements = 5, nNextFreeElement = 0,
pInternalPointer = 0xce76c8, pListHead = 0xce76c8, pListTail = 0xce7850,
arBuckets = 0xcde670,
pDestructor = 0x586190 zend_destroy_property_info, persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, default_static_members =
{nTableSize = 8, nTableMask = 7,
nNumOfElements = 0, nNextFreeElement = 0, pInternalPointer = 0x0, pListHead
= 0x0, pListTail = 0x0, arBuckets = 0xcde6c0, pDestructor = 0x595420
_zval_ptr_dtor, persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, static_members = 0x0,
constants_table = {nTableSize = 8, nTableMask = 7, nNumOfElements = 0,
nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead = 0x0, pListTail = 0x0, arBuckets = 0xcde710, pDestructor =
0x595420 _zval_ptr_dtor, persistent = 0 '\000', nApplyCount = 0 '\000',
bApplyProtection = 0 '\000'}, builtin_functions = 0x0,
constructor = 0xca2160, destructor = 0x0, clone = 0x0, __get = 0x0, __set =
0x0, __unset = 0x0, __isset = 0x0, __call = 0x0, __callstatic = 0x0, __tostring
= 0x0, serialize_func = 0x0,
unserialize_func = 0x0, iterator_funcs = {funcs = 0x0, zf_new_iterator = 0x0,
zf_valid = 0x0, zf_current = 0x0, zf_key = 0x0, zf_next = 0x0, zf_rewind =
0x0},
create_object = 0, get_iterator = 0,
interface_gets_implemented = 0, get_static_method = 0, serialize = 0,
unserialize = 0, interfaces = 0xcde368, num_interfaces = 1,
filename = 0xcde018 [...]/Introspection
[PHP-BUG] Bug #60457 [NEW]: gc_zval_possible_root SIGSEGV
From:
Operating system: Linux
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Bug
Bug description:gc_zval_possible_root SIGSEGV
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in
an
application consisting of many classes. I have been poking at this with gdb
for a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause
this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage
(object=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=value optimized
out) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object-properties);
(gdb) print *object-ce
$1 = {type = 2 '\002', name = 0xcdce30 React_Introspection_Controller,
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001',
ce_flags = 0, function_table = {nTableSize = 32,
nTableMask = 31, nNumOfElements = 27, nNextFreeElement = 0,
pInternalPointer
= 0xcde7b0, pListHead = 0xcde7b0, pListTail = 0xce9d10, arBuckets =
0xce8fa8,
pDestructor = 0x599450 zend_function_dtor,
persistent = 0 '\000', nApplyCount = 0 '\000', bApplyProtection = 0
'\000'},
default_properties = {nTableSize = 8, nTableMask = 7, nNumOfElements = 5,
nNextFreeElement = 0, pInternalPointer = 0xce74c8,
pListHead = 0xce74c8, pListTail = 0xce7660, arBuckets = 0xcdcf50,
pDestructor = 0x595420 _zval_ptr_dtor, persistent = 0 '\000', nApplyCount
= 0
'\000', bApplyProtection = 0 '\000'}, properties_info = {
nTableSize = 8, nTableMask = 7, nNumOfElements = 5, nNextFreeElement =
0,
pInternalPointer = 0xce76c8, pListHead = 0xce76c8, pListTail = 0xce7850,
arBuckets = 0xcde670,
pDestructor = 0x586190 zend_destroy_property_info, persistent = 0
'\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'},
default_static_members =
{nTableSize = 8, nTableMask = 7,
nNumOfElements = 0, nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead
= 0x0, pListTail = 0x0, arBuckets = 0xcde6c0, pDestructor = 0x595420
_zval_ptr_dtor, persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, static_members =
0x0,
constants_table = {nTableSize = 8, nTableMask = 7, nNumOfElements = 0,
nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead = 0x0, pListTail = 0x0, arBuckets = 0xcde710, pDestructor =
0x595420 _zval_ptr_dtor, persistent = 0 '\000', nApplyCount = 0 '\000',
bApplyProtection = 0 '\000'}, builtin_functions = 0x0,
constructor = 0xca2160, destructor = 0x0, clone = 0x0, __get = 0x0, __set
=
0x0, __unset = 0x0, __isset = 0x0, __call = 0x0, __callstatic = 0x0,
__tostring
= 0x0, serialize_func = 0x0,
unserialize_func = 0x0, iterator_funcs = {funcs = 0x0, zf_new_iterator =
0x0,
zf_valid = 0x0, zf_current = 0x0, zf_key = 0x0, zf_next = 0x0, zf_rewind =
0x0},
create_object = 0, get_iterator = 0,
interface_gets_implemented = 0, get_static_method = 0, serialize = 0,
unserialize = 0, interfaces = 0xcde368, num_interfaces = 1,
filename = 0xcde018 [...]/Introspection/Controller.php, line_start = 2,
line_end = 82, doc_comment = 0x0,
doc_comment_len = 0, module = 0x0}
--
Edit bug report at https://bugs.php.net/bug.php?id=60457edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60457r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60457r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60457r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60457r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60457r=needdocs
Fixed in release:
[PHP-BUG] Bug #55223 [NEW]: isset triggers fatal error when accessing object as array
From: Operating system: Archlinux PHP version: 5.3.6 Package: Arrays related Bug Type: Bug Bug description:isset triggers fatal error when accessing object as array Description: This worked for quite a long time, but stopped working recently, I suspect due to #53971 being fixed. I think isset should never trigger any error Test script: --- $x = new stdClass; $x-a = 'b'; var_dump(isset($x['a'])); Expected result: false Actual result: -- PHP Fatal error: Cannot use object of type stdClass as array in php shell code on line 1 -- Edit bug report at https://bugs.php.net/bug.php?id=55223edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55223r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55223r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55223r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55223r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55223r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55223r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55223r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55223r=needscript Try newer version: https://bugs.php.net/fix.php?id=55223r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55223r=support Expected behavior: https://bugs.php.net/fix.php?id=55223r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55223r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55223r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55223r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55223r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55223r=dst IIS Stability: https://bugs.php.net/fix.php?id=55223r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55223r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55223r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55223r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55223r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55223r=trysnapshot54
#46945 [NEW]: overwriting containing variable via extract segfaults in _zend_is_inconsistent
From: sjon at hortensius dot net
Operating system: Linux
PHP version: 5.2.8
PHP Bug Type: Reproducible crash
Bug description: overwriting containing variable via extract segfaults in
_zend_is_inconsistent
Description:
The supplied code shouldn't crash
Reproduce code:
---
$x = array('x' = 9);
extract($x);
Actual result:
--
#0 0x08279691 in _zend_is_inconsistent (ht=0x9,
file=0x850ada4 /tmp/php/src/php-5.2.8/Zend/zend_hash.c, line=1277)
at /tmp/php/src/php-5.2.8/Zend/zend_hash.c:54
#1 0x0827c8c0 in zend_hash_move_forward_ex (ht=0x9, pos=0xbfabdc68)
at /tmp/php/src/php-5.2.8/Zend/zend_hash.c:1277
#2 0x0817d0e9 in zif_extract (ht=1, return_value=0x95da738,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /tmp/php/src/php-5.2.8/ext/standard/array.c:1491
#3 0x08294a64 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfabde78)
at /tmp/php/src/php-5.2.8/Zend/zend_vm_execute.h:200
#4 0x0829a367 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfabde78)
at /tmp/php/src/php-5.2.8/Zend/zend_vm_execute.h:1729
#5 0x082945e4 in execute (op_array=0x95da104)
at /tmp/php/src/php-5.2.8/Zend/zend_vm_execute.h:92
#6 0x0826f70c in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /tmp/php/src/php-5.2.8/Zend/zend.c:1215
#7 0x0821c793 in php_execute_script (primary_file=0xbfac0204)
at /tmp/php/src/php-5.2.8/main/main.c:2044
#8 0x082ee8b6 in main (argc=2, argv=0xbfac0364)
at /tmp/php/src/php-5.2.8/sapi/cli/php_cli.c:1139
--
Edit bug report at http://bugs.php.net/?id=46945edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46945r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46945r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46945r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46945r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46945r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46945r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46945r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46945r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46945r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46945r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46945r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46945r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46945r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46945r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46945r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46945r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46945r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46945r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46945r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46945r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46945r=mysqlcfg
#41835 [NEW]: PCRE Update request
From: Sjon at hortensius dot net Operating system: PHP version: 5.2.3 PHP Bug Type: Feature/Change Request Bug description: PCRE Update request Description: The latest version of the PCRE library is 7.2 which fixes a bug I frequently experience problems with. However, PHP 5.2.3 is still shipped with PCRE library 7.0. Could this please be updated? -- Edit bug report at http://bugs.php.net/?id=41835edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41835r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41835r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41835r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41835r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41835r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41835r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41835r=needscript Try newer version:http://bugs.php.net/fix.php?id=41835r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41835r=support Expected behavior:http://bugs.php.net/fix.php?id=41835r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41835r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41835r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41835r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41835r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41835r=dst IIS Stability:http://bugs.php.net/fix.php?id=41835r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41835r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41835r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41835r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41835r=mysqlcfg
#41835 [Csd]: PCRE Update request
ID: 41835 User updated by: Sjon at hortensius dot net Reported By: Sjon at hortensius dot net Status: Closed Bug Type:Feature/Change Request PHP Version: 5.2.3 New Comment: Of course I wouldn't expect 5.2.3 to be updated; but if 5.2.4 contains it I am more then happy Previous Comments: [2007-06-28 08:25:54] [EMAIL PROTECTED] We can't go back to the future and change already released 5.2.3, but 5.2.4-CVS already contains PCRE 7.2 [2007-06-28 08:06:27] Sjon at hortensius dot net Description: The latest version of the PCRE library is 7.2 which fixes a bug I frequently experience problems with. However, PHP 5.2.3 is still shipped with PCRE library 7.0. Could this please be updated? -- Edit this bug report at http://bugs.php.net/?id=41835edit=1
#41788 [NEW]: preg_replace_callback returns NULL instead of input or error
From: Sjon at hortensius dot net
Operating system: linux 2.6.21.5
PHP version: 5.2.3
PHP Bug Type: Regexps related
Bug description: preg_replace_callback returns NULL instead of input or error
Description:
The preg_replace_callback manual-entry says:
If matches are found, the new subject will be returned, otherwise subject
will be returned unchanged.
However; I have a testcase where no input is returned; and my callback
isn't called either. This seems to be caused by a required
pcre.backtrack_limit of 1000
Shouldn't PHP return the input or an error giving some pointers about this
limit being reached?
Reproduce code:
---
?PHP
$input = '{?value==input.value}';
$regexp = '~\{\?(?:\(?!?.+(==)?.+\)?)+\}{\1\/}~sU';
var_dump(preg_replace_callback($regexp, 'callback', $input));
function callback(){
die('called');
}
Expected result:
I expect an error to be raised when pcre.backtrack_limit is reached
Actual result:
--
NULL is var_dumped
--
Edit bug report at http://bugs.php.net/?id=41788edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41788r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41788r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41788r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41788r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41788r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41788r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41788r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41788r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41788r=support
Expected behavior:http://bugs.php.net/fix.php?id=41788r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41788r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41788r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41788r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41788r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41788r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41788r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41788r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41788r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41788r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41788r=mysqlcfg
#41306 [NEW]: PHP Segfaults on certain regexp
From: Sjon at hortensius dot net
Operating system: Linux 2.6.20
PHP version: 4.4.7
PHP Bug Type: PCRE related
Bug description: PHP Segfaults on certain regexp
Description:
Although other regexps work fine; this one crashes since 4.4.7 is
installed
Reproduce code:
---
?PHP
$x = new x();
class x {
function y($matches){
echo 'no problem!';
}
function x(){
preg_replace_callback('~\{([a-zA-Z\-_]{0,50})@([a-zA-Z_\d]{1,50})\}((?:(?:\{[a-zA-Z.\-_\d]{1,50}\}|[^\{\}]*)(\{,\})?)*)\{\1/\}~sU',
array($this, 'y'), '[EMAIL PROTECTED]/}');
}
}
?
Expected result:
I would expect the x::y function to be ran by preg_replace_callback
Actual result:
--
[Sun May 06 20:47:49 2007] [notice] child pid 26044 exit signal
Segmentation fault (11)
--
Edit bug report at http://bugs.php.net/?id=41306edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41306r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41306r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41306r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41306r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41306r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41306r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41306r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41306r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41306r=support
Expected behavior:http://bugs.php.net/fix.php?id=41306r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41306r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41306r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41306r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41306r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41306r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41306r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41306r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41306r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41306r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41306r=mysqlcfg
#41306 [Opn]: preg_replace_callback segfaults on certain regexp
ID: 41306
User updated by: Sjon at hortensius dot net
-Summary: PHP Segfaults on certain regexp
Reported By: Sjon at hortensius dot net
Status: Open
Bug Type: PCRE related
Operating System: Linux 2.6.20
PHP Version: 4.4.7
New Comment:
The backtrace is _very_ long. Here is the first part:
Program received signal SIGSEGV, Segmentation fault.
match (eptr=0x82a3b47 argument{/}, ecode=0x82a37a5 O, offset_top=6,
md=0xbfeac6ac, ims=4, eptrb=0x0, flags=0, rdepth=11366)
at
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:372
372 /root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:
No such file or directory.
in
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c
(gdb) bt
#0 match (eptr=0x82a3b47 argument{/}, ecode=0x82a37a5 O,
offset_top=6, md=0xbfeac6ac, ims=4, eptrb=0x0, flags=0, rdepth=11366)
at
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:372
#1 0x0807e197 in match (eptr=0x82a3b47 argument{/}, ecode=value
optimized out, offset_top=6, md=0xbfeac6ac, ims=4, eptrb=0x0, flags=0,
rdepth=11365)
at
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:1187
#2 0x0807a5e0 in match (eptr=value optimized out, ecode=value
optimized out, offset_top=value optimized out, md=0xbfeac6ac, ims=4,
eptrb=0x0,
flags=value optimized out, rdepth=11364) at
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:1082
#3 0x0807e560 in match (eptr=value optimized out, ecode=value
optimized out, offset_top=value optimized out, md=0xbfeac6ac, ims=4,
eptrb=0x0,
flags=value optimized out, rdepth=11363) at
/root/packages/php/src/php-4.4.7/ext/pcre/pcrelib/pcre_exec.c:1740
Previous Comments:
[2007-05-06 19:12:58] Sjon at hortensius dot net
Description:
Although other regexps work fine; this one crashes since 4.4.7 is
installed
Reproduce code:
---
?PHP
$x = new x();
class x {
function y($matches){
echo 'no problem!';
}
function x(){
preg_replace_callback('~\{([a-zA-Z\-_]{0,50})@([a-zA-Z_\d]{1,50})\}((?:(?:\{[a-zA-Z.\-_\d]{1,50}\}|[^\{\}]*)(\{,\})?)*)\{\1/\}~sU',
array($this, 'y'), '[EMAIL PROTECTED]/}');
}
}
?
Expected result:
I would expect the x::y function to be ran by preg_replace_callback
Actual result:
--
[Sun May 06 20:47:49 2007] [notice] child pid 26044 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=41306edit=1
