[PHP-BUG] Bug #60841 [NEW]: expand_filepath fails to resolve symlinks that point to \xxx\yyy
From: cataphract
Operating system: Windows 7
PHP version: 5.3.9
Package: Filesystem function related
Bug Type: Bug
Bug description:expand_filepath fails to resolve symlinks that point to \xxx\yyy
Description:
If a path includes a symlink that points to a path like \xxx\yyy, PHP
understands
it as a relative path, while it's actually an absolute path (or
quasi-absolute,
as it doesn't have a drive letter).
Expected result:
foocontents
Actual result:
--
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cd \
C:\>mkdir t
C:\>mkdir t\test
C:\>mklink /D t\testlink \t\test
symbolic link created for t\testlink <<===>> \t\test
C:\>echo foocontents > \t\testlink\foo
C:\>php -r "echo file_get_contents('t\testlink\foo');"
Warning: file_get_contents(t\testlink\foo): failed to open stream: No such
file
or directory in Command line code on line 1
C:\>php -r "echo file_get_contents('t\test\foo');"
foocontents
C:\>type t\testlink\foo
foocontents
--
Edit bug report at https://bugs.php.net/bug.php?id=60841&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60841&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60841&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60841&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60841&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60841&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60841&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60841&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60841&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60841&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60841&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60841&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60841&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60841&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60841&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60841&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60841&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60841&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60841&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60841&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60841&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60841&r=mysqlcfg
[PHP-BUG] Bug #60965 [NEW]: Buffer overflow on htmlspecialchars/entities with $double=false
From: cataphract Operating system: Any PHP version: 5.4SVN-2012-02-03 (SVN) Package: Reproducible crash Bug Type: Bug Bug description:Buffer overflow on htmlspecialchars/entities with $double=false Description: Long entities can cause a buffer overflow because the loop only guarantees 40 bytes available in beginning. Test script: --- https://bugs.php.net/bug.php?id=60965&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60965&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60965&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60965&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60965&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60965&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60965&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60965&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60965&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60965&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60965&r=support Expected behavior: https://bugs.php.net/fix.php?id=60965&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60965&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60965&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60965&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60965&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60965&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60965&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60965&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60965&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60965&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60965&r=mysqlcfg
[PHP-BUG] Bug #61000 [NEW]: Exceeding max nesting level doesn't delete numerical vars
From: cataphract Operating system: Irrelevant PHP version: trunk-SVN-2012-02-07 (snap) Package: Scripting Engine problem Bug Type: Bug Bug description:Exceeding max nesting level doesn't delete numerical vars Description: Exceeding the max nesting level doesn't delete numerical vars, while it deletes the non-numerical ones. php_register_variable_ex inappropriately uses zend_hash_del. (Found out by Stefan Esser, who points this can be used, together with max_input_vars, to determine whether PHP is a 32-bit or 64-bit process) Test script: --- With max nesting level=2: http://nebm.ist.utl.pt/phpinfo?1[a][]=foo&1[a][b][c]=bar Expected result: _GET is empty Actual result: -- _GET["1"] = Array ( [a] => Array ( [0] => foo ) ) -- Edit bug report at https://bugs.php.net/bug.php?id=61000&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61000&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61000&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61000&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61000&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61000&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61000&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61000&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61000&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61000&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61000&r=support Expected behavior: https://bugs.php.net/fix.php?id=61000&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61000&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61000&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61000&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61000&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61000&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61000&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61000&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61000&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61000&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61000&r=mysqlcfg
[PHP-BUG] Bug #61253 [NEW]: Wrappers opened with errors concurrency problem
From: cataphract Operating system: Any (ZTS) PHP version: 5.4SVN-2012-03-02 (SVN) Package: Streams related Bug Type: Bug Bug description:Wrappers opened with errors concurrency problem Description: When opening the same wrapper in several threads and this generates errors, a segfault may result. Test script: --- http://localhost/notfound'); Expected result: Each requests shows a 404 error. Actual result: -- Segfault given enough concurrency -- Edit bug report at https://bugs.php.net/bug.php?id=61253&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61253&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61253&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61253&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61253&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61253&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61253&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61253&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61253&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61253&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61253&r=support Expected behavior: https://bugs.php.net/fix.php?id=61253&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61253&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61253&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61253&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61253&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61253&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61253&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61253&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61253&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61253&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61253&r=mysqlcfg
Bug #61253 [PATCH]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1 ID: 61253 Patch added by: [email protected] Reported by:[email protected] Summary:Wrappers opened with errors concurrency problem Status: Open Type: Bug Package:Streams related Operating System: Any (ZTS) PHP Version:5.4SVN-2012-03-02 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61253.diff Revision: 1330726381 URL: https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381 Previous Comments: [2012-03-02 22:08:08] [email protected] Description: When opening the same wrapper in several threads and this generates errors, a segfault may result. Test script: --- http://localhost/notfound'); Expected result: Each requests shows a 404 error. Actual result: -- Segfault given enough concurrency -- Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
Bug #61253 [PATCH]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1 ID: 61253 Patch added by: [email protected] Reported by:[email protected] Summary:Wrappers opened with errors concurrency problem Status: Assigned Type: Bug Package:Streams related Operating System: Any (ZTS) PHP Version:5.4SVN-2012-03-02 (SVN) Assigned To:mattficken Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61253.diff Revision: 1331129135 URL: https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1331129135 Previous Comments: [2012-03-03 20:42:12] [email protected] Matt, can you test this patch please? and add the test to our suites while being at it :) [2012-03-02 22:13:36] [email protected] Pierre, please see if this fixes the problem. [2012-03-02 22:13:02] [email protected] The following patch has been added/updated: Patch Name: bug61253.diff Revision: 1330726381 URL: https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381 [2012-03-02 22:08:08] [email protected] Description: When opening the same wrapper in several threads and this generates errors, a segfault may result. Test script: --- http://localhost/notfound'); Expected result: Each requests shows a 404 error. Actual result: -- Segfault given enough concurrency -- Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
[PHP-BUG] Bug #61374 [NEW]: html_entity_decode tries to decode code points that don't exist in ISO-8859-1
From: cataphract Operating system: Irrelevant PHP version: 5.4SVN-2012-03-13 (SVN) Package: *General Issues Bug Type: Bug Bug description:html_entity_decode tries to decode code points that don't exist in ISO-8859-1 Description: html_entity_decode tries to decode code points that don't exist in ISO-8859-1. The result is that the codepoint(s) being written mod 256. Test script: --- https://bugs.php.net/bug.php?id=61374&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61374&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61374&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61374&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61374&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61374&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61374&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61374&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61374&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61374&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61374&r=support Expected behavior: https://bugs.php.net/fix.php?id=61374&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61374&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61374&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61374&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61374&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61374&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61374&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61374&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61374&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61374&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61374&r=mysqlcfg
[PHP-BUG] Bug #62120 [NEW]: PDO mishandles build outside of tree
From: cataphract Operating system: Linux PHP version: master-Git-2012-05-23 (Git) Package: Compile Failure Bug Type: Bug Bug description:PDO mishandles build outside of tree Description: If you have a different configuration in the tree, when you configure PHP outside the tree and build PDO, the build will either fail (if you include pdo-sqlite) or it will fail at runtime due to missing symbols. Actual result: -- In file included from /home/gustavo/php-src/main/php_compat.h:27, from /home/gustavo/php-src/main/php.h:36, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /tmp/t/main/php_config.h:2179:1: warning: "PHP_BUILD_DATE" redefined In file included from /tmp/t/TSRM/tsrm_config.h:1, from /home/gustavo/php-src/Zend/../TSRM/TSRM.h:20, from /home/gustavo/php-src/Zend/zend_alloc.h:27, from /home/gustavo/php-src/Zend/zend.h:237, from /home/gustavo/php-src/main/php.h:34, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /home/gustavo/php-src/ext/../main/php_config.h:2179:1: warning: this is the location of the previous definition In file included from /home/gustavo/php-src/main/php_compat.h:27, from /home/gustavo/php-src/main/php.h:36, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /tmp/t/main/php_config.h:2404:1: warning: "ZEND_DEBUG" redefined In file included from /tmp/t/TSRM/tsrm_config.h:1, from /home/gustavo/php-src/Zend/../TSRM/TSRM.h:20, from /home/gustavo/php-src/Zend/zend_alloc.h:27, from /home/gustavo/php-src/Zend/zend.h:237, from /home/gustavo/php-src/main/php.h:34, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /home/gustavo/php-src/ext/../main/php_config.h:2404:1: warning: this is the location of the previous definition In file included from /tmp/t/TSRM/tsrm_config.h:1, from /home/gustavo/php-src/TSRM/tsrm_config_common.h:13, from /home/gustavo/php-src/TSRM/tsrm_virtual_cwd.h:27, from /home/gustavo/php-src/main/php.h:401, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /home/gustavo/php-src/ext/../main/php_config.h:2179:1: warning: "PHP_BUILD_DATE" redefined In file included from /home/gustavo/php-src/main/php_compat.h:27, from /home/gustavo/php-src/main/php.h:36, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /tmp/t/main/php_config.h:2179:1: warning: this is the location of the previous definition In file included from /tmp/t/TSRM/tsrm_config.h:1, from /home/gustavo/php-src/TSRM/tsrm_config_common.h:13, from /home/gustavo/php-src/TSRM/tsrm_virtual_cwd.h:27, from /home/gustavo/php-src/main/php.h:401, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /home/gustavo/php-src/ext/../main/php_config.h:2404:1: warning: "ZEND_DEBUG" redefined In file included from /home/gustavo/php-src/main/php_compat.h:27, from /home/gustavo/php-src/main/php.h:36, from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26: /tmp/t/main/php_config.h:2404:1: warning: this is the location of the previous definition -- Edit bug report at https://bugs.php.net/bug.php?id=62120&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62120&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62120&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62120&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62120&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62120&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62120&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62120&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62120&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62120&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62120&r=support Expected behavior: https://bugs.php.net/fix.php?id=62120&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62120&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62120&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62120&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62120&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62120&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62120&r=isapi Install GNU Sed:
[PHP-BUG] Bug #62690 [NEW]: Sibling property with same name accessible in sibling is detected as accessible
From: cataphract
Operating system: Irrelevant
PHP version: master-Git-2012-07-29 (Git)
Package: Reflection related
Bug Type: Bug
Bug description:Sibling property with same name accessible in sibling is
detected as accessible
Description:
See script.
Test script:
---
getProperty('var');
echo $prop->getValue(new Qux());
Expected result:
A 'ReflectionException' with message 'Given object is not an instance of
the class this property was declared in'.
This would mirror the behavior with methods:
getMethod('foo');
$meth->invoke(new Qux());
PHP Fatal error: Uncaught exception 'ReflectionException' with message
'Given object is not an instance of the class this method was declared in'
Actual result:
--
PHP Fatal error: Cannot access private property Qux::$var
--
Edit bug report at https://bugs.php.net/bug.php?id=62690&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62690&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62690&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62690&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62690&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62690&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62690&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62690&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62690&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62690&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62690&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62690&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62690&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62690&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62690&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62690&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62690&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62690&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62690&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62690&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62690&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62690&r=mysqlcfg
[PHP-BUG] Bug #62694 [NEW]: Obtaining the value of inexistent dynamic properties should not be allowed
From: cataphract
Operating system: Irrelevant
PHP version: master-Git-2012-07-30 (Git)
Package: Reflection related
Bug Type: Bug
Bug description:Obtaining the value of inexistent dynamic properties should not
be allowed
Description:
The reflection extension does not allow obtaining ReflectionProperty
objects for non existent properties, much less fetch their non existent
value. However, this can be bypassed by creating a dynamic
ReflectionProperty in another object.
Test script:
---
foo = "dynamic property";
$ro = new ReflectionObject($a);
$prop = $ro->getProperty('foo');
try {
var_dump($prop->getValue($a));
var_dump($prop->getValue(new A));
} catch (ReflectionException $ex) {
echo "Caught!\n";
try {
var_dump($prop->getValue(new A));
} catch (ReflectionException $ex) {
var_dump($ex->getMessage());
}
}
Expected result:
string(16) "dynamic property"
Caught!
string(49) "Dynamic property does not exist in given instance"
Actual result:
--
string(16) "dynamic property"
NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=62694&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62694&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62694&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62694&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62694&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62694&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62694&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62694&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62694&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62694&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62694&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62694&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62694&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62694&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62694&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62694&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62694&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62694&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62694&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62694&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62694&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62694&r=mysqlcfg
[PHP-BUG] Bug #62938 [NEW]: zend_do_bind_catch() used without declaration
From: cataphract
Operating system: Linux/clang
PHP version: master-Git-2012-08-26 (Git)
Package: Compile Warning
Bug Type: Bug
Bug description:zend_do_bind_catch() used without declaration
Description:
zend_do_bind_catch() used without declaration. The line that raises the
issue was last modified in c64f4e73.
Actual result:
--
/opt/php-src/Zend/zend_language_parser.y:318:7: warning: implicit
declaration of function 'zend_do_bind_catch' is invalid in C99
[-Wimplicit-function-declaration]
{ zend_do_bind_catch(&(yyvsp[(1) - (6)]), &(yyvsp[(6) - (6)])
TSRMLS_CC); }
^
1 warning generated.
--
Edit bug report at https://bugs.php.net/bug.php?id=62938&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62938&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62938&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62938&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62938&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62938&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62938&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62938&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62938&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62938&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62938&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62938&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62938&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62938&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62938&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62938&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62938&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62938&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62938&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62938&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62938&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62938&r=mysqlcfg
[PHP-BUG] Bug #51768 [NEW]: Fallback to read_property causes subsequent crash
From: cataphract
Operating system: Windows
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:Fallback to read_property causes subsequent crash
Description:
When the get_property_ptr_ptr handler is omitted,
zend_fetch_property_address falls back to read_property, but then the
behavior in cases such as
$a = &$obj->prop;
deviates from that of
$a = &$obj['prop'];
which properly emits an error.
The final result is a crash.
Test script:
---
exttest.h:
#ifndef PHP_EXTTEST_H
# define PHP_EXTTEST_H
# ifdef HAVE_CONFIG_H
# include
# endif
# include
extern zend_module_entry exttest_module_entry;
#define phpext_exttest_ptr &exttest_module_entry
#endif
exttest.c:
#include "exttest.h"
static zend_object_handlers object_handlers;
static zend_object_value ce_create_object(zend_class_entry *class_type
TSRMLS_DC)
{
zend_object_value zov;
zend_object *zobj;
zobj = emalloc(sizeof *zobj);
zend_object_std_init(zobj, class_type TSRMLS_CC);
zend_hash_copy(zobj->properties, &(class_type->default_properties),
(copy_ctor_func_t) zval_add_ref, NULL, sizeof(zval*));
zov.handle = zend_objects_store_put(zobj,
(zend_objects_store_dtor_t) zend_objects_destroy_object,
(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,
NULL TSRMLS_CC);
zov.handlers = &object_handlers;
return zov;
}
ZEND_MODULE_STARTUP_D(exttest)
{
zend_class_entry ce;
zend_class_entry *ce_ptr;
zval *property;
ALLOC_PERMANENT_ZVAL(property);
INIT_ZVAL(*property);
Z_TYPE_P(property) = IS_LONG;
Z_LVAL_P(property) = 20l;
memcpy(&object_handlers, zend_get_std_object_handlers(),
sizeof object_handlers);
object_handlers.get_property_ptr_ptr = NULL;
INIT_CLASS_ENTRY(ce, "TestClass", NULL);
ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);
ce_ptr->create_object = ce_create_object;
zend_declare_property_ex(ce_ptr, "prop", 4, property, ZEND_ACC_PUBLIC,
NULL, 0 TSRMLS_CC);
}
zend_module_entry exttest_module_entry = {
STANDARD_MODULE_HEADER,
"exttest",
NULL, /* Functions */
ZEND_MODULE_STARTUP_N(exttest) , /* MINIT */
NULL, /* MSHUTDOWN */
NULL, /* RINIT */
NULL, /* RSHUTDOWN */
NULL, /* MINFO */
NO_VERSION_YET,
STANDARD_MODULE_PROPERTIES
};
ZEND_GET_MODULE(exttest)
config.m4:
PHP_ARG_ENABLE(exttest,
[Whether to enable the "exttest" extension],
[ enable-exttest Enable "exttest" extension support])
if test $PHP_EXTTEST != "no"; then
PHP_SUBST(EXTTEST_SHARED_LIBADD)
PHP_NEW_EXTENSION(exttest, exttest.c, $ext_shared)
fi
test.php:
prop;
debug_zval_dump($obj);
debug_zval_dump(&$a);
$a = 40;
debug_zval_dump($obj);
debug_zval_dump(&$a);
unset($a);
debug_zval_dump($obj);
Expected result:
Expected an error saying the operation is not permitted (like when
attempting $a = &obj['index'] where there's no get_property_ptr_ptr
equivalent).
Actual result:
--
When thre's get_property_ptr_ptr:
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(20) refcount(2)
}
object(TestClass)#1 (1) refcount(2){
["prop"]=>
&long(20) refcount(2)
}
&long(20) refcount(3)
object(TestClass)#1 (1) refcount(2){
["prop"]=>
&long(40) refcount(2)
}
&long(40) refcount(3)
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(40) refcount(1)
}
When there's no get_property_ptr_ptr, zend_fetch_property_address falls
back to read_propert. Something happens afterwards that provokes the
crash.
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(20) refcount(2)
}
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(20) refcount(1)
}
&long(20) refcount(3)
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(20) refcount(1)
}
&long(40) refcount(3)
object(TestClass)#1 (1) refcount(2){
["prop"]=>
long(20) refcount(1)
}
Segmentation fault
#0 0x081d60ae in zend_mm_check_ptr (heap=0x83881b8, ptr=0x840ca90,
silent=1,
__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,
__zend_orig_filename=0x83621b8
"/home/glopes/php/php-5.3.2/Zend/zend_execute_API.c",
__zend_orig_lineno=440) at
/home/glopes/php/php-5.3.2/Zend/zend_alloc.c:1347
#1 0x081d768d in _zend_mm_free_int (heap=0x83881b8, p=0x840ca90,
__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,
__zend_orig_filename=0x83621b8
"/home/glopes/php/php-5.3.2/Zend/zend_execute_API.c",
__zend_orig_lineno=440) at
/home/glopes/php/php-5.3.2/Zend/zend_alloc.c:1983
#2 0x081d86bb in _efree (ptr=0x840ca90,
__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,
__zend_orig_filename=0x83621b8
"/home/glopes/php/ph
Bug #51763 [Com]: SplFileInfo::getType()
Edit report at http://bugs.php.net/bug.php?id=51763&edit=1 ID: 51763 Comment by: [email protected] Reported by: v-sumada at microsoft dot com Summary: SplFileInfo::getType() Status: Open Type: Bug Package: SPL related Operating System: All windows OS PHP Version: 5.3.2 New Comment: The comment should read "information is NOT conveyed in the stat structure". Previous Comments: [2010-05-08 05:05:38] [email protected] This is unrelated to Spl. is_link/etc. are all also windows symbolic link agnostic. The problem here is that this information is conveyed in the stat structure. Strictly speaking, the return of getType is not completely incorrect -- the file type _S_IFREG and symbolic links are in fact files or (empty) directories with reparse point data. Maybe the best thing to do would be to change the stat function returned on windows so that the file type is replaced with _S_IFLNK when the directory is a junction/symlink or the file is a symlink. [2010-05-07 03:36:11] v-sumada at microsoft dot com Description: The SplFileInfo::getType() For Symbolic link returns "dir" which in turn should return "link" .This happens to be in 5.3.2 and occurs on all windows OS. It Correctly returns the type of file referenced which is for Dir and File . getType()); ?> Expected result :string(4)"Link" Actual result : string(3) "dir" Test script: --- getType()); ?> Expected result: string(4)"Link" Actual result: -- string(3) "dir" -- Edit this bug report at http://bugs.php.net/bug.php?id=51763&edit=1
[PHP-BUG] Bug #52063 [NEW]: DateTime constructor's second argument doesn't have a null default value
From: cataphract
Operating system: Irrelevant
PHP version: 5.3.2
Package: Date/time related
Bug Type: Bug
Bug description:DateTime constructor's second argument doesn't have a null
default value
Description:
DateTime's constructor is documented like this:
public DateTime::__construct ([ string $time = "now" [, DateTimeZone
$timezone = NULL ]] )
However, not passing the constructor the second argument is not the same as
passing NULL. Fixing this is just a matter of adding a "!", like this
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
into
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO!",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
Test script:
---
format(DateTime::COOKIE);
Expected result:
Thursday, 01-Jan-09 00:00:00 WET
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() expects parameter 2 to be DateTimeZone, null
given' in /tmp/cpCZPA42:4 Stack trace: #0 /tmp/cpCZPA42(4):
DateTime->__construct('2009-01-01', NULL) #1 {main} thrown in /tmp/cpCZPA42
on line 4
--
Edit bug report at http://bugs.php.net/bug.php?id=52063&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52063&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52063&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52063&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52063&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52063&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52063&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52063&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52063&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52063&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52063&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52063&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52063&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52063&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52063&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52063&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52063&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52063&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52063&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52063&r=mysqlcfg
[PHP-BUG] Bug #52539 [NEW]: Calling function from rebound Closure causes crash
From: cataphract
Operating system: Windows
PHP version: trunk-SVN-2010-08-05 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Calling function from rebound Closure causes crash
Description:
Calling a function in a rebound closure causes a crash.
This seems to be caused by dmitry's optimizations because this fixes the
issue:
#define CACHED_PTR(num) 0.
Test script:
---
class foo {
static function getClosure() {
return static function () {
//causes a crash (fbc not properly defined) in call
after rebinding
echo get_called_class(), "\n";
};
}
}
class subFoo { }
$c = foo::getClosure();
$c(); //foo
$c = $c->bindTo(new subFoo());
$c(); //crash
Expected result:
No crash.
Actual result:
--
> php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8) Line 302 + 0x3
bytes C
php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8) Line 1721 C
php5ts_debug.dll!execute(_zend_op_array * op_array=0x025f23c8, void * *
*
tsrm_ls=0x02784bf8) Line 136 + 0x11 bytes C
php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x02784bf8, _zval_struct * * retval=0x, int file_count=3,
...) Line 1193 + 0x21 bytesC
php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x00aaf7b0, void * * * tsrm_ls=0x02784bf8) Line 2330 + 0x1b
bytes C
php.exe!main(int argc=2, char * * argv=0x02784af8) Line 1252 + 0x13
bytes C
--
Edit bug report at http://bugs.php.net/bug.php?id=52539&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52539&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52539&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52539&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52539&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52539&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52539&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52539&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52539&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52539&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52539&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52539&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52539&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52539&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52539&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52539&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52539&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52539&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52539&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52539&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52539&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52539&r=mysqlcfg
Bug #52539 [PATCH]: Calling function from rebound Closure causes crash
Edit report at http://bugs.php.net/bug.php?id=52539&edit=1 ID: 52539 Patch added by: [email protected] Reported by:[email protected] Summary:Calling function from rebound Closure causes crash Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:trunk-SVN-2010-08-05 (SVN) Assigned To:dmitry Block user comment: N New Comment: The following patch has been added/updated: Patch Name: patch_closures_rebind Revision: 1281277806 URL: http://bugs.php.net/patch-display.php?bug=52539&patch=patch_closures_rebind&revision=1281277806 Previous Comments: [2010-08-05 09:34:56] [email protected] Description: Calling a function in a rebound closure causes a crash. This seems to be caused by dmitry's optimizations because this fixes the issue: #define CACHED_PTR(num) 0. Test script: --- class foo { static function getClosure() { return static function () { //causes a crash (fbc not properly defined) in call after rebinding echo get_called_class(), "\n"; }; } } class subFoo { } $c = foo::getClosure(); $c(); //foo $c = $c->bindTo(new subFoo()); $c(); //crash Expected result: No crash. Actual result: -- > php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8) Line 302 + 0x3 bytes C php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8) Line 1721 C php5ts_debug.dll!execute(_zend_op_array * op_array=0x025f23c8, void * * * tsrm_ls=0x02784bf8) Line 136 + 0x11 bytes C php5ts_debug.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x02784bf8, _zval_struct * * retval=0x, int file_count=3, ...) Line 1193 + 0x21 bytes C php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file=0x00aaf7b0, void * * * tsrm_ls=0x02784bf8) Line 2330 + 0x1b bytes C php.exe!main(int argc=2, char * * argv=0x02784af8) Line 1252 + 0x13 bytes C -- Edit this bug report at http://bugs.php.net/bug.php?id=52539&edit=1
[PHP-BUG] Bug #52772 [NEW]: var_dump() doesn't check for the existence of get_class_name before calling it
From: cataphract
Operating system: Windows
PHP version: trunk-SVN-2010-09-04 (snap)
Package: Variables related
Bug Type: Bug
Bug description:var_dump() doesn't check for the existence of get_class_name
before calling it
Description:
php_var_dump has a NULL pointer dereference in var.c:136
Z_OBJ_HANDLER(**struc, get_class_name)(*struc, &class_name,
&class_name_len, 0 TSRMLS_CC);
It doesn't check the existence of the handler get_class_name before
calling. In particular, it will crash when given a proxy object.
The engine always checks for the existence of this handler before calling.
See e.g. the definitions of ZEND_FUNCTION(get_parent_class) and
zend_print_flat_zval_r:
http://lxr.php.net/search?q=%22ZEND_FUNCTION%28get_parent_class%29%22&project=PHP_TRUNK&defs=&refs=&path=&hist=
http://lxr.php.net/search?q=zend_print_flat_zval_r&project=PHP_TRUNK&defs=&refs=&path=&hist=
Test script:
---
/* Extension */
typedef struct _proxy_test {
zend_object std;
long value;
} proxy_test;
static zend_class_entry *pt_ce_ptr;
static zend_object_handlers p_obj_handlers;
static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)
{
zend_object_value zov;
proxy_test *pobj;
pobj = emalloc(sizeof *pobj);
zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);
pobj->value = 7;
object_properties_init(&pobj->std, class_type);
zov.handle = zend_objects_store_put(pobj,
(zend_objects_store_dtor_t) zend_objects_destroy_object,
(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,
NULL TSRMLS_CC);
zov.handlers = &p_obj_handlers;
return zov;
}
zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {
zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);
Z_DELREF_P(ret);
return ret;
} else {
zval *ret;
MAKE_STD_ZVAL(ret);
ZVAL_LONG(ret, iobj->value);
Z_DELREF_P(ret);
return ret;
}
}
void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (Z_TYPE_P(value) == IS_LONG) {
iobj->value = Z_LVAL_P(value);
}
}
zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)
{
return NULL;
}
/*static zend_function_entry proxy_test_methods[] = {
{NULL, NULL, NULL, 0, 0}
};*/
ZEND_MODULE_STARTUP_D(testext)
{
zend_class_entry ce;
INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);
pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);
pt_ce_ptr->create_object = p_ce_create_object;
memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);
/* could be NULL, but an empty impl is better (see bug #51768) */
p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;
p_obj_handlers.read_property = p_read_property;
p_obj_handlers.write_property = p_write_property;
}
/* Script */
whatever;
var_dump($h); NULL-pointer dereference on handler get_class_name
Expected result:
No crash. Possibly, var_dump could show "proxy object" and show the zval
returned by the get handler or it could just fail.
Actual result:
--
()
> php5ts_debug.dll!php_var_dump(_zval_struct * * struc=0x010a22a8, int
level=1, void * * * tsrm_ls=0x00fc4bf8) Line 136 + 0x23 bytes C
php5ts_debug.dll!zif_var_dump(int ht=1, _zval_struct *
return_value=0x010bf3f0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x, int return_value_used=0, void * * *
tsrm_ls=0x00fc4bf8) Line 181 + 0x15 bytes C
php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x010a20d8, void * * * tsrm_ls=0x00fc4bf8) Line 638 + 0x5f
bytes C
php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x010a20d8, void * * * tsrm_ls=0x00fc4bf8) Line 2018 C
php5ts_debug.dll!execute(_zend_op_array * op_array=0x010c0dc8, void * *
*
tsrm_ls=0x00fc4bf8) Line 410 + 0x11 bytes C
php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x00fc4bf8, _zval_struct * * retval=0x, int file_count=3,
...) Line 1193 + 0x21 bytesC
php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x0095fb48, void * * * tsrm_ls=0x00fc4bf8) Line 2330 + 0x1b
bytes C
[PHP-BUG] Bug #52773 [NEW]: Proxy objects have an inadequate destroy_object store callback
From: cataphract
Operating system: Windows
PHP version: trunk-SVN-2010-09-04 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Proxy objects have an inadequate destroy_object store callback
Description:
zend_object_create_proxy calls zend_objects_store_put with the second
argument NULL:
See the definition of zend_object_create-proxy:
http://lxr.php.net/search?q=zend_object_create_proxy&project=PHP_TRUNK&defs=&refs=&path=&hist=
This results in the _store_object.dtor store callback being set to
zend_objects_destroy_object. See the definition of zend_objects_store_put:
http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_objects_API.c#zend_objects_store_put
This callback is defined here:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_objects.c#zend_objects_destroy_object
It is inappropriate because it starts with:
ZEND_API void zend_objects_destroy_object(zend_object *object,
zend_object_handle handle TSRMLS_DC)
{
zend_function *destructor = object ? object->ce->destructor : NULL;
The first parameter won't actually be a zend_object; it'll be a
zend_proxy_object, whose definition is not compatible with that of
zend_object:
typedef struct _zend_object {
zend_class_entry *ce;
HashTable *properties;
zval **properties_table;
HashTable *guards; /* protects from __get/__set ... recursion */
} zend_object;
typedef struct _zend_proxy_object {
zval *object;
zval *property;
} zend_proxy_object;
Test script:
---
/* Extension */
typedef struct _proxy_test {
zend_object std;
long value;
} proxy_test;
static zend_class_entry *pt_ce_ptr;
static zend_object_handlers p_obj_handlers;
static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)
{
zend_object_value zov;
proxy_test *pobj;
pobj = emalloc(sizeof *pobj);
zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);
pobj->value = 7;
object_properties_init(&pobj->std, class_type);
zov.handle = zend_objects_store_put(pobj,
(zend_objects_store_dtor_t) zend_objects_destroy_object,
(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,
NULL TSRMLS_CC);
zov.handlers = &p_obj_handlers;
return zov;
}
zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {
zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);
Z_DELREF_P(ret);
return ret;
} else {
zval *ret;
MAKE_STD_ZVAL(ret);
ZVAL_LONG(ret, iobj->value);
Z_DELREF_P(ret);
return ret;
}
}
void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (Z_TYPE_P(value) == IS_LONG) {
iobj->value = Z_LVAL_P(value);
}
}
zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)
{
return NULL;
}
/*static zend_function_entry proxy_test_methods[] = {
{NULL, NULL, NULL, 0, 0}
};*/
ZEND_MODULE_STARTUP_D(testext)
{
zend_class_entry ce;
INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);
pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);
pt_ce_ptr->create_object = p_ce_create_object;
memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);
/* could be NULL, but an empty impl is better (see bug #51768) */
p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;
p_obj_handlers.read_property = p_read_property;
p_obj_handlers.write_property = p_write_property;
}
/* Script */
whatever;
unset($h);
Expected result:
zend_objects_destroy_object should not be the proxy object's destructor.
A no-op destructor should be passed to the store_put function.
Actual result:
--
I didn't get a crash by change (the memory in object->ce->destructor turned
out to be zeroed, which makes zend_objects_destroy_object skip the
implementation), but we can see this doesn't make sense:
Breakpoint with this stack:
> php5ts_debug.dll!zend_objects_destroy_object(_zend_object *
object=0x011bf680, unsigned int handle=2, void * * * tsrm_ls=0x001d15f8)
Line 62 C
php5ts_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int
handle=2, const _zend_object_handlers * handlers=0x5d6fb848, void * * *
tsrm_ls=0x001d15f8) Line 206 + 0x18 bytes C
php5ts_debug.dll!zend_obje
[PHP-BUG] Bug #52774 [NEW]: Proxy object's store free callback calls zval_ptor_dtor on already freed data
From: cataphract
Operating system:
PHP version: trunk-SVN-2010-09-04 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Proxy object's store free callback calls zval_ptor_dtor on
already freed data
Description:
Proxy objects have this structure:
typedef struct _zend_proxy_object {
zval *object;
zval *property;
} zend_proxy_object;
zend_object_create_proxy does this:
ZEND_API zval *zend_object_create_proxy(zval *object, zval *member
TSRMLS_DC)
{
zend_proxy_object *pobj = emalloc(sizeof(zend_proxy_object));
/* ... */
pobj->property = member;
zval_add_ref(&pobj->property);
/* ... */
}
The property field is used to store a zval that, in the get and set
handlers can the passed to zend_proxy_object.object's read_property and
write_property callbacks, so that the reads and writes in the proxy object
can be proxied.
The store free callback for proxy objects calls zval_ptr_tor on
&pobj->property:
ZEND_API void zend_objects_proxy_free_storage(zend_proxy_object *object
TSRMLS_DC)
{
zval_ptr_dtor(&object->object);
zval_ptr_dtor(&object->property);
efree(object);
}
However, on script cleanup, the destruction order is wrong. The zval stored
in object->property is destroyed *before* the proxy object is.
Test script:
---
/* Extension */
typedef struct _proxy_test {
zend_object std;
long value;
} proxy_test;
static zend_class_entry *pt_ce_ptr;
static zend_object_handlers p_obj_handlers;
static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)
{
zend_object_value zov;
proxy_test *pobj;
pobj = emalloc(sizeof *pobj);
zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);
pobj->value = 7;
object_properties_init(&pobj->std, class_type);
zov.handle = zend_objects_store_put(pobj,
(zend_objects_store_dtor_t) zend_objects_destroy_object,
(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,
NULL TSRMLS_CC);
zov.handlers = &p_obj_handlers;
return zov;
}
zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {
zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);
Z_DELREF_P(ret);
return ret;
} else {
zval *ret;
MAKE_STD_ZVAL(ret);
ZVAL_LONG(ret, iobj->value);
Z_DELREF_P(ret);
return ret;
}
}
void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)
{
proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);
if (Z_TYPE_P(value) == IS_LONG) {
iobj->value = Z_LVAL_P(value);
}
}
zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)
{
return NULL;
}
ZEND_MODULE_STARTUP_D(testext)
{
zend_class_entry ce;
INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);
pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);
pt_ce_ptr->create_object = p_ce_create_object;
memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);
/* could be NULL, but an empty impl is better (see bug #51768) */
p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;
p_obj_handlers.read_property = p_read_property;
p_obj_handlers.write_property = p_write_property;
}
/* Script */
whatever;
Expected result:
The proxy object would be destroyed before the property zval encapsulated
in it.
Actual result:
--
The property zval encapsulated in the proxy object is destroyed
prematurely.
Breakpoint on zend_object_create_proxy. Set data breakpoint on
&member->refcount__gc
Continue. Data breakpoint is hit (zval_add_ref(&pobj->property);). The
refcount is now 3.
Continue. Data breakpoint is hit. Call stack:
> msvcr100d.dll!memset(unsigned char * dst=0x005a, unsigned char
value='`', unsigned long count=11071032) Line 127 Asm
php5ts_debug.dll!_zend_mm_free_int(_zend_mm_heap * heap=0x02426d50, void
* p=0x028101a0, const char * __zend_filename=0x5d637b70, const unsigned int
__zend_lineno=397, const char * __zend_orig_filename=0x, const
unsigned int __zend_orig_lineno=0) Line 2019 + 0x15 bytes C
php5ts_debug.dll!_efree(void * ptr=0x028101a0, const char *
__zend_filename=0x5d637b70, const unsigned int __zend_lineno=397, const
char * __zend_orig_filename=0x, const unsigned int
__zend_orig_lineno=0)
[PHP-BUG] Bug #52785 [NEW]: CGI: error_log may result in output before the headers
From: cataphract Operating system: Debian Lenny PHP version: 5.3.3 Package: CGI related Bug Type: Bug Bug description:CGI: error_log may result in output before the headers Description: A call to error_log may result in data being output before the headers, thereby corrupting the response. The same doesn't happen with other PHP output functions. The ini directive error_log is set to "no value". The docs say "If this directive is not set, errors are sent to the SAPI error logger". Test script: --- Fatal error: Call to undefined function inexistent_function() in /home/glopes/test.php on line 4 Actual result: -- $ /opt/php5/bin/php-cgi test.php oops X-Powered-By: PHP/5.3.3 Content-type: text/html content Fatal error: Call to undefined function inexistent_function() in /home/glopes/test.php on line 4 -- Edit bug report at http://bugs.php.net/bug.php?id=52785&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52785&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52785&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52785&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52785&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52785&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52785&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52785&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52785&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52785&r=support Expected behavior: http://bugs.php.net/fix.php?id=52785&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52785&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52785&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52785&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52785&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52785&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52785&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52785&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52785&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52785&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52785&r=mysqlcfg
Bug #50953 [PATCH]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=50953&edit=1 ID: 50953 Patch added by: [email protected] Reported by:tony at marston-home dot demon dot co dot uk Summary:fsockopen will not work on 'localhost' Status: Bogus Type: Bug Package:Sockets related Operating System: Windows XP PHP Version:5.2.12 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: connect_fix_win32 Revision: 1283848007 URL: http://bugs.php.net/patch-display.php?bug=50953&patch=connect_fix_win32&revision=1283848007 Previous Comments: [2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk If IPv6 support is enabled in the operating system it does NOT mean that only IPv6 addresses are allowed, it means that both IPv5 and IPv6 addresses are supported. All of my web browsers (IE, Firefox, Opera, Safari) have no problem in translating 'localhost' to '127.0.0.1'. The PHP gethostbyname() function has no problem in translating 'localhost' to '127.0.0.1'. The PHP cURL extension has no problem in translating 'localhost' to '127.0.0.1'. fsockopen() when running in PHP 5.3.0 has no problem in translating 'localhost' to '127.0.0.1'. So why does fsockopen() in php 5.2.12 have a problem? [2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk This has got nothing to do with IPV6 addresses as my hosts file does not contain anf IPV6 addresses. All it has is as follows: 127.0.0.1 localhost Every other piece of software on my PC uses 'loalhost' without a problem, so should fsockopen in PHP. Curl can manage it, so why not fsockopen. I have the same setup on another PC which runs Windows XP with IPV6 support and PHP 5.3.0, and it does not have a problem with 'localhost', so this is a genuine bug in 5.2 Do not keep telling me that you have already addressed this issue in other posts because you have not. You nhave suggested removing any IPV6 entries from the hosts file, which I have done, but this does not fix the problem. If gethostbyname() can work with 'localhost' then why can't fsockopen()? [2010-02-10 11:06:08] [email protected] It works just fine here using localhost and ipv4. You are clearly experiencing the IPv6 problem described in a good dozen bugs here (with solutions). I'm sorry if it is not acceptable but we can't do anything about that, see the other reports for a complete and detailed explanation. [2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk THIS IS NOT BOGUS, IT IS A GENUINE BUG!!! If print_r(gethostbynamel('localhost')); produces the following: Array ( [0] => 127.0.0.1 ) then why can't fsockopen connect to 'localhost'? It is a valid name which is recognised by every other piece of software on my computer, so there is no good reason why fsockopen should have a problem with it. I have another PC which runs 5.3.0 where fsockopen does not have a problem with 'localhost', therefore there is a bug in 5.2 [2010-02-10 10:18:16] [email protected] Already explained why it can't and won't be fixed in 5.2, neither in 5.3. Use the IP then instead of the hostname. Bogus (duplicated, not really a bug per se but a feature,etc.) 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 http://bugs.php.net/bug.php?id=50953 -- Edit this bug report at http://bugs.php.net/bug.php?id=50953&edit=1
Bug #52789 [Com]: microtime() loses time in long-running scripts (please reopen)
Edit report at http://bugs.php.net/bug.php?id=52789&edit=1 ID: 52789 Comment by: [email protected] Reported by:jdolecek at NetBSD dot org Summary:microtime() loses time in long-running scripts (please reopen) Status: Open Type: Bug Package:Date/time related Operating System: Windows XP PHP Version:5.3.3 Block user comment: N New Comment: I ran the script for two hours and a half and couldn't reproduce it. Is this XP only? Previous Comments: [2010-09-07 09:40:11] jdolecek at NetBSD dot org Description: This is just a reminder for Bug #42659 since I cannot reopen that one. The problem with time difference between time() and microtime() on Windows XP is still there. Please reopen Bug #42659 -- Edit this bug report at http://bugs.php.net/bug.php?id=52789&edit=1
Bug #52798 [PATCH]: dateTime => function diff => days KO
Edit report at http://bugs.php.net/bug.php?id=52798&edit=1 ID: 52798 Patch added by: [email protected] Reported by:ebinachon at pierre-vacances dot fr Summary:dateTime => function diff => days KO Status: Verified Type: Bug Package:Date/time related Operating System: windows xp PHP Version:5.3.3 Assigned To:derick Block user comment: N New Comment: The following patch has been added/updated: Patch Name: date_diff Revision: 1283961826 URL: http://bugs.php.net/patch-display.php?bug=52798&patch=date_diff&revision=1283961826 Previous Comments: [2010-09-08 17:36:02] [email protected] I can reproduce only on Windows. The exactly value varies (seems to be garbage memory). [2010-09-08 17:19:52] ebinachon at pierre-vacances dot fr Description: I have a probleme with the function diff of dateTime. When i do a test, the "days" result is always : 6015. All the other informations ( Y, m, d, ... ) are correct. Have-you an idea ? Test script: --- Exemple : $date1 = new DateTime('2010-01-01'); $date2 = new DateTime('2010-03-13'); $interval = $date2->diff($date1); Zend_Debug::dump($interval); //OR Zend_Debug::dump($interval->format('%a')); -- Result : object(DateInterval)#174 (8) { ["y"] => int(0) ["m"] => int(2) ["d"] => int(12) ["h"] => int(0) ["i"] => int(0) ["s"] => int(0) ["invert"] => int(0) ["days"] => int(6015) } Expected result: days => 71 Actual result: -- days => 6015 -- Edit this bug report at http://bugs.php.net/bug.php?id=52798&edit=1
[PHP-BUG] Bug #52802 [NEW]: Out-of-date comment for file_get_contents/php_stream_copy_to_mem
From: cataphract
Operating system:
PHP version: trunk-SVN-2010-09-09 (SVN)
Package: Streams related
Bug Type: Bug
Bug description:Out-of-date comment for file_get_contents/php_stream_copy_to_mem
Description:
ext/standard/file.c#560
560 /* uses mmap if possible */
561 if ((len = php_stream_copy_to_mem(stream, &contents, maxlen,
0)) >
0) {
main/php_streams.h
431 /* read all data from stream and put into a buffer. Caller must
free buffer when done.
432 * The copy will use mmap if available. */
433 PHPAPI size_t _php_stream_copy_to_mem(php_stream *src, char **buf,
size_t maxlen,
434 int persistent STREAMS_DC TSRMLS_DC);
435 #define php_stream_copy_to_mem(src, buf, maxlen, persistent)
_php_stream_copy_to_mem((src), (buf), (maxlen), (persistent) STREAMS_CC
TSRMLS_CC)
main/php_streams.h
419 /* copy up to maxlen bytes from src to dest. If maxlen is
PHP_STREAM_COPY_ALL, copy until eof(src).
420 * Uses mmap if the src is a plain file and at offset 0 */
421 #define PHP_STREAM_COPY_ALL ((size_t)-1)
In this last case, PHP_STREAM_COPY_ALL is also passed to
php_stream_copy_to_stream_ex, which still uses mmap+mmap_unmap, so it's
half correct (except for the part is works with any maxlen, not just
PHP_STREAM_COPY_ALL).
--
Edit bug report at http://bugs.php.net/bug.php?id=52802&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52802&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52802&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52802&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52802&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52802&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52802&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52802&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52802&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52802&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52802&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52802&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52802&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52802&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52802&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52802&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52802&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52802&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52802&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52802&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52802&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52802&r=mysqlcfg
Bug #52802 [Com]: Out-of-date comment for file_get_contents/php_stream_copy_to_mem
Edit report at http://bugs.php.net/bug.php?id=52802&edit=1 ID: 52802 Comment by: [email protected] Reported by:[email protected] Summary:Out-of-date comment for file_get_contents/php_stream_copy_to_mem Status: Open Type: Bug Package:Streams related PHP Version:trunk-SVN-2010-09-09 (SVN) Block user comment: N New Comment: Forgot the tell. The behavior of php_stream_copy_to_mem was modified in March 2008: http://svn.php.net/viewvc?view=revision&revision=255970 Previous Comments: [2010-09-09 13:36:58] [email protected] Description: ext/standard/file.c#560 560 /* uses mmap if possible */ 561 if ((len = php_stream_copy_to_mem(stream, &contents, maxlen, 0)) > 0) { main/php_streams.h 431 /* read all data from stream and put into a buffer. Caller must free buffer when done. 432 * The copy will use mmap if available. */ 433 PHPAPI size_t _php_stream_copy_to_mem(php_stream *src, char **buf, size_t maxlen, 434 int persistent STREAMS_DC TSRMLS_DC); 435 #define php_stream_copy_to_mem(src, buf, maxlen, persistent) _php_stream_copy_to_mem((src), (buf), (maxlen), (persistent) STREAMS_CC TSRMLS_CC) main/php_streams.h 419 /* copy up to maxlen bytes from src to dest. If maxlen is PHP_STREAM_COPY_ALL, copy until eof(src). 420 * Uses mmap if the src is a plain file and at offset 0 */ 421 #define PHP_STREAM_COPY_ALL ((size_t)-1) In this last case, PHP_STREAM_COPY_ALL is also passed to php_stream_copy_to_stream_ex, which still uses mmap+mmap_unmap, so it's half correct (except for the part is works with any maxlen, not just PHP_STREAM_COPY_ALL). -- Edit this bug report at http://bugs.php.net/bug.php?id=52802&edit=1
[PHP-BUG] Bug #52827 [NEW]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)
From: cataphract Operating system: Ubuntu 10.4 x64; Windows 7 x64 PHP version: 5.3.3 Package: cURL related Bug Type: Bug Bug description:cURL leaks handle and causes assertion error (CURLOPT_STDERR) Description: curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and increments both the refcount of the zval* and of the resource. Only the refcount of the zval should be incremented. Additionally, due to a flaw in the streams API, this leak results in an assertion error. The reason is that on shutdown the unexposed/leaked resources are destroyed in reverse order, so the encapsulated STDIO stream is destroyed first and when the TEMP stream is destroyed, it then tries to close the encapsulated STDIO steam again. I will submit this as a separate bug report. Test script: --- http://www.example.com'); curl_setopt($handle, CURLOPT_STDERR, $s); Expected result: No output. Actual result: -- (with stream debug) stream_alloc: TEMP:0x12a61b0 persistent=(null) stream_alloc: MEMORY:0x12a6488 persistent=(null) stream_alloc: STDIO:0x12a6f90 persistent=(null) stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003 stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1 remove_rs rc=1 stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0 release_cast=1 re move_rsrc=1 /tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO' 0x12a6f90 (p ath:/tmp/phpghmjqQ) was not closed stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0 opts=000b stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0 release _cast=1 remove_rsrc=1 php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush: Assertio n `data != ((void *)0)' failed. Aborted #0 0x7f74b5a22ed5 in raise () from /lib/libc.so.6 #1 0x7f74b5a243f3 in abort () from /lib/libc.so.6 #2 0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6 #3 0x0076129e in php_stdiop_flush (stream=0x1049dc8) at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434 #4 0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0) at /tmp/php-5.3.3/main/streams/streams.c:1050 #5 0x0075df57 in php_stream_temp_flush (stream=0x1049050) at /tmp/php-5.3.3/main/streams/memory.c:440 #6 0x007596dd in _php_stream_flush (stream=0x1049050, closing=1) at /tmp/php-5.3.3/main/streams/streams.c:1050 #7 0x00757b4d in _php_stream_free (stream=0x1049050, close_options=11) at /tmp/php-5.3.3/main/streams/streams.c:331 #8 0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48) at /tmp/php-5.3.3/main/streams/streams.c:1426 #9 0x007c4f9e in list_entry_destructor (ptr=0x104ab48) at /tmp/php-5.3.3/Zend/zend_list.c:184 #10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650, p=0x1049198) at /tmp/php-5.3.3/Zend/zend_hash.c:611 #11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_hash.c:646 #12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_list.c:240 #13 0x007b1549 in zend_deactivate () at /tmp/php-5.3.3/Zend/zend.c:896 #14 0x0073e71b in php_request_shutdown (dummy=0x0) at /tmp/php-5.3.3/main/main.c:1633 #15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8) at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373 -- Edit bug report at http://bugs.php.net/bug.php?id=52827&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52827&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52827&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52827&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52827&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52827&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52827&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52827&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52827&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52827&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52827&r=support Expected behavior: http://bugs.php.net/fix.php?id=52827&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52827&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52827&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52827&r=globals PHP 4 support discontinued:
Bug #52827 [PATCH]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)
Edit report at http://bugs.php.net/bug.php?id=52827&edit=1 ID: 52827 Patch added by: [email protected] Reported by:[email protected] Summary:cURL leaks handle and causes assertion error (CURLOPT_STDERR) Status: Open Type: Bug Package:cURL related Operating System: Ubuntu 10.4 x64; Windows 7 x64 PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: curlopt_stderr Revision: 1284389761 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761 Previous Comments: [2010-09-13 16:55:39] [email protected] Description: curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and increments both the refcount of the zval* and of the resource. Only the refcount of the zval should be incremented. Additionally, due to a flaw in the streams API, this leak results in an assertion error. The reason is that on shutdown the unexposed/leaked resources are destroyed in reverse order, so the encapsulated STDIO stream is destroyed first and when the TEMP stream is destroyed, it then tries to close the encapsulated STDIO steam again. I will submit this as a separate bug report. Test script: --- http://www.example.com'); curl_setopt($handle, CURLOPT_STDERR, $s); Expected result: No output. Actual result: -- (with stream debug) stream_alloc: TEMP:0x12a61b0 persistent=(null) stream_alloc: MEMORY:0x12a6488 persistent=(null) stream_alloc: STDIO:0x12a6f90 persistent=(null) stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003 stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1 remove_rs rc=1 stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0 release_cast=1 re move_rsrc=1 /tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO' 0x12a6f90 (p ath:/tmp/phpghmjqQ) was not closed stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0 opts=000b stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0 release _cast=1 remove_rsrc=1 php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush: Assertio n `data != ((void *)0)' failed. Aborted #0 0x7f74b5a22ed5 in raise () from /lib/libc.so.6 #1 0x7f74b5a243f3 in abort () from /lib/libc.so.6 #2 0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6 #3 0x0076129e in php_stdiop_flush (stream=0x1049dc8) at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434 #4 0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0) at /tmp/php-5.3.3/main/streams/streams.c:1050 #5 0x0075df57 in php_stream_temp_flush (stream=0x1049050) at /tmp/php-5.3.3/main/streams/memory.c:440 #6 0x007596dd in _php_stream_flush (stream=0x1049050, closing=1) at /tmp/php-5.3.3/main/streams/streams.c:1050 #7 0x00757b4d in _php_stream_free (stream=0x1049050, close_options=11) at /tmp/php-5.3.3/main/streams/streams.c:331 #8 0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48) at /tmp/php-5.3.3/main/streams/streams.c:1426 #9 0x007c4f9e in list_entry_destructor (ptr=0x104ab48) at /tmp/php-5.3.3/Zend/zend_list.c:184 #10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650, p=0x1049198) at /tmp/php-5.3.3/Zend/zend_hash.c:611 #11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_hash.c:646 #12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_list.c:240 #13 0x007b1549 in zend_deactivate () at /tmp/php-5.3.3/Zend/zend.c:896 #14 0x0073e71b in php_request_shutdown (dummy=0x0) at /tmp/php-5.3.3/main/main.c:1633 #15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8) at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373 -- Edit this bug report at http://bugs.php.net/bug.php?id=52827&edit=1
[PHP-BUG] Bug #52828 [NEW]: curl_setopt does not accept persistent streams
From: cataphract Operating system: Irrelevant PHP version: 5.3.3 Package: cURL related Bug Type: Bug Bug description:curl_setopt does not accept persistent streams Description: The options CURLOPT_FILE, CURLOPT_INFILE, CURLOPT_WRITEHEADER and CURLOPT_STDERR do not accept persistent handles. Since there appears to be special no reason for that, it's probably of a simple mistake of not including the return of php_file_le_pstream() in the list of accepted resource types. -- Edit bug report at http://bugs.php.net/bug.php?id=52828&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52828&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52828&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52828&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52828&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52828&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52828&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52828&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52828&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52828&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52828&r=support Expected behavior: http://bugs.php.net/fix.php?id=52828&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52828&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52828&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52828&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52828&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52828&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52828&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52828&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52828&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52828&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52828&r=mysqlcfg
Bug #52827 [PATCH]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)
Edit report at http://bugs.php.net/bug.php?id=52827&edit=1 ID: 52827 Patch added by: [email protected] Reported by:[email protected] Summary:cURL leaks handle and causes assertion error (CURLOPT_STDERR) Status: Open Type: Bug Package:cURL related Operating System: Debian Lenny x64; Windows 7 x64 PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: curlopt_stderr_with_test Revision: 1284403798 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr_with_test&revision=1284403798 Previous Comments: [2010-09-13 16:56:01] [email protected] The following patch has been added/updated: Patch Name: curlopt_stderr Revision: 1284389761 URL: http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761 [2010-09-13 16:55:39] [email protected] Description: curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and increments both the refcount of the zval* and of the resource. Only the refcount of the zval should be incremented. Additionally, due to a flaw in the streams API, this leak results in an assertion error. The reason is that on shutdown the unexposed/leaked resources are destroyed in reverse order, so the encapsulated STDIO stream is destroyed first and when the TEMP stream is destroyed, it then tries to close the encapsulated STDIO steam again. I will submit this as a separate bug report. Test script: --- http://www.example.com'); curl_setopt($handle, CURLOPT_STDERR, $s); Expected result: No output. Actual result: -- (with stream debug) stream_alloc: TEMP:0x12a61b0 persistent=(null) stream_alloc: MEMORY:0x12a6488 persistent=(null) stream_alloc: STDIO:0x12a6f90 persistent=(null) stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003 stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1 remove_rs rc=1 stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0 release_cast=1 re move_rsrc=1 /tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO' 0x12a6f90 (p ath:/tmp/phpghmjqQ) was not closed stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0 opts=000b stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0 release _cast=1 remove_rsrc=1 php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush: Assertio n `data != ((void *)0)' failed. Aborted #0 0x7f74b5a22ed5 in raise () from /lib/libc.so.6 #1 0x7f74b5a243f3 in abort () from /lib/libc.so.6 #2 0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6 #3 0x0076129e in php_stdiop_flush (stream=0x1049dc8) at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434 #4 0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0) at /tmp/php-5.3.3/main/streams/streams.c:1050 #5 0x0075df57 in php_stream_temp_flush (stream=0x1049050) at /tmp/php-5.3.3/main/streams/memory.c:440 #6 0x007596dd in _php_stream_flush (stream=0x1049050, closing=1) at /tmp/php-5.3.3/main/streams/streams.c:1050 #7 0x00757b4d in _php_stream_free (stream=0x1049050, close_options=11) at /tmp/php-5.3.3/main/streams/streams.c:331 #8 0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48) at /tmp/php-5.3.3/main/streams/streams.c:1426 #9 0x007c4f9e in list_entry_destructor (ptr=0x104ab48) at /tmp/php-5.3.3/Zend/zend_list.c:184 #10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650, p=0x1049198) at /tmp/php-5.3.3/Zend/zend_hash.c:611 #11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_hash.c:646 #12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650) at /tmp/php-5.3.3/Zend/zend_list.c:240 #13 0x007b1549 in zend_deactivate () at /tmp/php-5.3.3/Zend/zend.c:896 #14 0x0073e71b in php_request_shutdown (dummy=0x0) at /tmp/php-5.3.3/main/main.c:1633 #15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8) at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373 -- Edit this bug report at http://bugs.php.net/bug.php?id=52827&edit=1
[PHP-BUG] Req #52860 [NEW]: htmlspecialchars/htmlentities stripping invalid characters
From: cataphract
Operating system: Irrelevant
PHP version: trunk-SVN-2010-09-16 (SVN)
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:htmlspecialchars/htmlentities stripping invalid characters
Description:
htmlspecialchars() and htmlentities() are commonly used to convert
user-supplied text into text that's safe to output in an HTML or XML
document.
Actually, they are insufficient for this purpose, because characters that
are invalid in XML or XHTML are not stripped out.
In HTML, this results in an invalid document.
In XML, the result is worse because one will end-up with malformed XML.
Therefore, sanitation with htmlspecialchars can result in corrupted data.
Additionaly, when passed $double_encode == true, invalid character entities
(i.e. those which refer to invalid characters) should also be stripped
out.
See
* http://www.w3.org/TR/REC-xml/#NT-Char
* http://www.w3.org/TR/REC-xml/#NT-CharRef
Test script:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
Test
%s
XML;
}
elseif ($mode == "html") {
header("Content-type: text/html; charset=utf-8");
$templ = <
Test
%s
HTML;
}
else die("bad mode");
$data = "My data: <\x1F";
echo sprintf($templ, htmlentities($data, ENT_NOQUOTES, "UTF-8"));
Expected result:
At minimum, this should be documented in the manual pages for
htmlspecialchars and htmlentities.
A better solution would be to change those two functions to strip
characters outside the allowed range:
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]
Another alternative, which wouldn't break BC, would be to add another
function or another flag to htmlentities/htmlspecialchars (in addition to
ENT_NOQUOTES/ENT_QUOTES/ENT_COMPAT) that would strip out these characters,
possible plus those that authors are "encouraged to avoid":
[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],
[#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3],
[#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6],
[#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9],
[#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC],
[#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF],
[#x10FFFE-#x10].
Actual result:
--
The W3C validator gives an error:
You have used an illegal character in your text. HTML uses the standard
UNICODE Consortium character repertoire, and it leaves undefined (among
others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive)
that are sometimes used for typographical quote marks and similar in
proprietary character sets. The validator has found one of these undefined
characters in your document. The character may appear on your browser as a
curly quote, or a trademark symbol, or some other fancy glyph; on a
different computer, however, it will likely appear as a completely
different character, or nothing at all.
--
Edit bug report at http://bugs.php.net/bug.php?id=52860&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52860&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52860&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52860&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52860&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52860&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52860&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52860&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52860&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52860&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52860&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52860&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52860&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52860&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52860&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52860&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52860&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52860&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52860&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52860&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52860&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52860&r=mysqlcfg
Bug #52863 [Com]: PHP Crash - RAM consuming
Edit report at http://bugs.php.net/bug.php?id=52863&edit=1 ID: 52863 Comment by: [email protected] Reported by:g dot delaportas at gmail dot com Summary:PHP Crash - RAM consuming Status: Open Type: Bug Package:Reproducible crash Operating System: Windows 7 PHP Version:Irrelevant Block user comment: N New Comment: Did actually crash? Can you provide a backtrace? It's normal it consumes all the RAM (if you have no memory limit), since you are allocating memory recursively and indefinitely. Previous Comments: [2010-09-16 18:16:47] g dot delaportas at gmail dot com Description: I use only native PHP code with no extra plugins loaded. The PHP 5.3.1 crashes and consumes all the RAM when I use the script below. This also happens to all the versions after 5.3.1. Test script: --- class Test_Crash { private $virtual_func; public function __construct() { $this->virtual_func = new Test_Crash; } } -- Edit this bug report at http://bugs.php.net/bug.php?id=52863&edit=1
[PHP-BUG] Req #52874 [NEW]: Refactor big if condition w/ collateral effects and nested ternary statements
From: cataphract
Operating system: Irrelevant
PHP version: trunk-SVN-2010-09-18 (SVN)
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Refactor big if condition w/ collateral effects and nested
ternary statements
Description:
Two if conditions (one in zend_std_read_property and another in
zend_std_write_property) are very confusing and should be refactored.
Here's one:
493 if (EXPECTED(property_info != NULL) &&
494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0) &&
495 property_info->offset >= 0) ?
496 (zobj->properties ?
497 ((variable_ptr =
(zval**)zobj->properties_table[property_info->offset]) != NULL) :
498 (*(variable_ptr =
&zobj->properties_table[property_info->offset]) != NULL)) :
499 (EXPECTED(zobj->properties != NULL) &&
500 EXPECTED(zend_hash_quick_find(zobj->properties,
property_info->name, property_info->name_length+1, property_info->h, (void
**) &variable_ptr) == SUCCESS {
501 /* if we already have this value there, we don't
actually need to
do anything */
This is very non-obvious.
I've refactored the conditions, which I tested with no regressions in the
tests.
--
Edit bug report at http://bugs.php.net/bug.php?id=52874&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52874&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52874&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52874&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52874&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52874&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52874&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52874&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52874&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52874&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52874&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52874&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52874&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52874&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52874&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52874&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52874&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52874&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52874&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52874&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52874&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52874&r=mysqlcfg
Req #52874 [PATCH]: Refactor big if condition w/ collateral effects and nested ternary statements
Edit report at http://bugs.php.net/bug.php?id=52874&edit=1 ID: 52874 Patch added by: [email protected] Reported by:[email protected] Summary:Refactor big if condition w/ collateral effects and nested ternary statements Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Irrelevant PHP Version:trunk-SVN-2010-09-18 (SVN) Block user comment: N New Comment: The following patch has been added/updated: Patch Name: refact_if Revision: 1284773271 URL: http://bugs.php.net/patch-display.php?bug=52874&patch=refact_if&revision=1284773271 Previous Comments: [2010-09-18 03:27:28] [email protected] Description: Two if conditions (one in zend_std_read_property and another in zend_std_write_property) are very confusing and should be refactored. Here's one: 493 if (EXPECTED(property_info != NULL) && 494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0) && 495 property_info->offset >= 0) ? 496 (zobj->properties ? 497 ((variable_ptr = (zval**)zobj->properties_table[property_info->offset]) != NULL) : 498 (*(variable_ptr = &zobj->properties_table[property_info->offset]) != NULL)) : 499 (EXPECTED(zobj->properties != NULL) && 500 EXPECTED(zend_hash_quick_find(zobj->properties, property_info->name, property_info->name_length+1, property_info->h, (void **) &variable_ptr) == SUCCESS { 501 /* if we already have this value there, we don't actually need to do anything */ This is very non-obvious. I've refactored the conditions, which I tested with no regressions in the tests. -- Edit this bug report at http://bugs.php.net/bug.php?id=52874&edit=1
Req #52874 [Com]: Refactor big if condition w/ collateral effects and nested ternary statements
Edit report at http://bugs.php.net/bug.php?id=52874&edit=1 ID: 52874 Comment by: [email protected] Reported by:[email protected] Summary:Refactor big if condition w/ collateral effects and nested ternary statements Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Irrelevant PHP Version:trunk-SVN-2010-09-18 (SVN) Block user comment: N New Comment: It's not just non-obvious. It also makes debugging harder. If I segfault on the if condition, my debugger will show it as occurring in the last line of the if. Previous Comments: [2010-09-18 03:27:51] [email protected] The following patch has been added/updated: Patch Name: refact_if Revision: 1284773271 URL: http://bugs.php.net/patch-display.php?bug=52874&patch=refact_if&revision=1284773271 [2010-09-18 03:27:28] [email protected] Description: Two if conditions (one in zend_std_read_property and another in zend_std_write_property) are very confusing and should be refactored. Here's one: 493 if (EXPECTED(property_info != NULL) && 494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0) && 495 property_info->offset >= 0) ? 496 (zobj->properties ? 497 ((variable_ptr = (zval**)zobj->properties_table[property_info->offset]) != NULL) : 498 (*(variable_ptr = &zobj->properties_table[property_info->offset]) != NULL)) : 499 (EXPECTED(zobj->properties != NULL) && 500 EXPECTED(zend_hash_quick_find(zobj->properties, property_info->name, property_info->name_length+1, property_info->h, (void **) &variable_ptr) == SUCCESS { 501 /* if we already have this value there, we don't actually need to do anything */ This is very non-obvious. I've refactored the conditions, which I tested with no regressions in the tests. -- Edit this bug report at http://bugs.php.net/bug.php?id=52874&edit=1
Req #52860 [Com]: htmlspecialchars/htmlentities stripping invalid characters
Edit report at http://bugs.php.net/bug.php?id=52860&edit=1 ID: 52860 Comment by: [email protected] Reported by:[email protected] Summary:htmlspecialchars/htmlentities stripping invalid characters Status: Open Type: Feature/Change Request Package:*General Issues Operating System: Irrelevant PHP Version:trunk-SVN-2010-09-16 (SVN) Block user comment: N New Comment: HTML5 follows the same direction: 8.1.4 Character references [...] The numeric character reference forms described above are allowed to reference any Unicode code point other than U+, U+000D, permanently undefined Unicode characters (noncharacters), and control characters other than space characters. 8.2.2.3 Preprocessing the input stream [...] All U+ NULL characters and code points in the range U+D800 to U+DFFF in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs. Any occurrences of such characters and code points are parse errors. Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+, U+1FFFE, U+1, U+2FFFE, U+2, U+3FFFE, U+3, U+4FFFE, U+4, U+5FFFE, U+5, U+6FFFE, U+6, U+7FFFE, U+7, U+8FFFE, U+8, U+9FFFE, U+9, U+AFFFE, U+A, U+BFFFE, U+B, U+CFFFE, U+C, U+DFFFE, U+D, U+EFFFE, U+E, U+E, U+F, U+10FFFE, and U+10 are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters). Previous Comments: [2010-09-16 16:45:10] [email protected] Where it says "invalid in XML or XHTML are not stripped out" it should read "invalid in XML or HTML are not stripped out". The characters are also invalid in HTML. ---- [2010-09-16 13:57:42] [email protected] Description: htmlspecialchars() and htmlentities() are commonly used to convert user-supplied text into text that's safe to output in an HTML or XML document. Actually, they are insufficient for this purpose, because characters that are invalid in XML or XHTML are not stripped out. In HTML, this results in an invalid document. In XML, the result is worse because one will end-up with malformed XML. Therefore, sanitation with htmlspecialchars can result in corrupted data. Additionaly, when passed $double_encode == true, invalid character entities (i.e. those which refer to invalid characters) should also be stripped out. See * http://www.w3.org/TR/REC-xml/#NT-Char * http://www.w3.org/TR/REC-xml/#NT-CharRef Test script: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> Test %s XML; } elseif ($mode == "html") { header("Content-type: text/html; charset=utf-8"); $templ = <<http://www.w3.org/TR/html4/loose.dtd";> Test %s HTML; } else die("bad mode"); $data = "My data: <\x1F"; echo sprintf($templ, htmlentities($data, ENT_NOQUOTES, "UTF-8")); Expected result: At minimum, this should be documented in the manual pages for htmlspecialchars and htmlentities. A better solution would be to change those two functions to strip characters outside the allowed range: #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] Another alternative, which wouldn't break BC, would be to add another function or another flag to htmlentities/htmlspecialchars (in addition to ENT_NOQUOTES/ENT_QUOTES/ENT_COMPAT) that would strip out these characters, possible plus those that authors are "encouraged to avoid": [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF], [#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3], [#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6], [#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9], [#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC], [#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF], [#x10FFFE-#x10]. Actual result: -- The W3C validator gives an error: You have used an illegal character in your text. HTML uses the standard UNICODE Consortium character repertoire, and it leaves undefined (among others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive) that are sometimes used for typographical quote marks and similar in proprietary character sets. The validator has found one of these undefined characters in your document. The character may appear on your browser as a curly quote, or a trademark symbol, or some other fancy glyph; on a different computer, however, it will likely appear as a completely different character, or nothing at all.
Bug #52906 [PATCH]: gmp_mod returns negative result when non-negative is expected
Edit report at http://bugs.php.net/bug.php?id=52906&edit=1 ID: 52906 Patch added by: [email protected] Reported by:kkcagg at gmail dot com Summary:gmp_mod returns negative result when non-negative is expected Status: Analyzed Type: Bug Package:GNU MP related Operating System: Linux PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: gmp_mod Revision: 1285170233 URL: http://bugs.php.net/patch-display.php?bug=52906&patch=gmp_mod&revision=1285170233 Previous Comments: [2010-09-22 17:21:09] [email protected] This is a bug in the PHP extension. Worse, the result differs if you pass a GMP resource instead of an integer: $ php -r "echo gmp_intval(gmp_mod(-2, gmp_add(6,1)));" 5 The problem is that gmp_zval_binary_ui_op_ex changes the sign of the result if it uses the unsigned integer variant of the GMP API and the first operand is negative. This may be the correct for other binary functions (I haven't checked), but it isn't for mod. The documentation mirrors the upstream documentation, which says: « â Function: void mpz_mod (mpz_t r, mpz_t n, mpz_t d) â Function: unsigned long int mpz_mod_ui (mpz_t r, mpz_t n, unsigned long int d) Set r to n mod d. The sign of the divisor is ignored; the result is always non-negative. » http://gmplib.org/manual/Integer-Division.html#Integer-Division [2010-09-22 11:48:29] kkcagg at gmail dot com Description: GMP version 4.2.2 Running the function in test script returns the output of -5 when 5 is expected. Documentation (http://us.php.net/manual/en/function.gmp-mod.php) asserts that the result is always non-negative. This is not the case in actuality. Bug type could be either a bug or documentation problem. Test script: --- Expected result: 5 Actual result: -- -5 -- Edit this bug report at http://bugs.php.net/bug.php?id=52906&edit=1
Bug #52926 [PATCH]: stream_context_set_default() does not work as intended with stream chaining
Edit report at http://bugs.php.net/bug.php?id=52926&edit=1 ID: 52926 Patch added by: [email protected] Reported by:simast at gmail dot com Summary:stream_context_set_default() does not work as intended with stream chaining Status: Analyzed Type: Bug Package:Zlib Related Operating System: Windows PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: zlib_inner_open Revision: 1285530552 URL: http://bugs.php.net/patch-display.php?bug=52926&patch=zlib_inner_open&revision=1285530552 Previous Comments: [2010-09-26 21:48:49] [email protected] Fixed in attached patch. The problem is php_stream_gzopen doesn't forward the context when opening the inner stream; this isn't limited to default contexts. [2010-09-26 15:07:20] simast at gmail dot com Description: Hello! I was trying to add gzip/deflate support to standard HTTP streams (code attached). It seems stream_context_set_default() works fine as long as stream wrappers are not chained, like when used with "compress.zlib://" it will not use options as set with this function and will revert to php default ones. Simas Test script: --- stream_context_set_default(array( 'http' => array( 'protocol_version' => 1.1, // HTTP 1.1 compatible 'header' => array( 'Connection: close', // No Keep-Alive 'Accept-Encoding: gzip, deflate' // We support content compression ) ) )); file_get_contents('compress.zlib://http://example.com'); Expected result: Default stream options should be used for chained streams as well. -- Edit this bug report at http://bugs.php.net/bug.php?id=52926&edit=1
[PHP-BUG] Bug #52939 [NEW]: zend_call_function does not respect ZEND_SEND_PREFER_REF
From: cataphract Operating system: Windows 7 x64 PHP version: trunk-SVN-2010-09-28 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:zend_call_function does not respect ZEND_SEND_PREFER_REF Description: The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it were ZEND_SEND_BY_REF. Test script: --- refcount__gc); php_var_dump(params[i], 0 TSRMLS_CC); } efree(params); } ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3) ZEND_ARG_INFO(0, req_pass_by_val) ZEND_ARG_INFO(1, req_pass_by_ref) ZEND_ARG_INFO(2, req_prefer_ pass_by_ref) ZEND_END_ARG_INFO() Expected result: Both calls would be successful. Actual result: -- Only the direct call is successful: direct call [0x5ddbed0, refcount=1] int(1) [0x5ddc530, refcount=2] &string(1) "a" [0x5ddbf20, refcount=1] int(7) call via zend_call_function PHP Warning: Parameter 3 to test_passing() expected to be a reference, value gi ven in - on line 12 -- Edit bug report at http://bugs.php.net/bug.php?id=52939&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52939&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52939&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52939&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52939&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52939&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52939&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52939&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52939&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52939&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52939&r=support Expected behavior: http://bugs.php.net/fix.php?id=52939&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52939&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52939&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52939&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52939&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52939&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52939&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52939&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52939&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52939&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52939&r=mysqlcfg
Bug #52939 [PATCH]: zend_call_function does not respect ZEND_SEND_PREFER_REF
Edit report at http://bugs.php.net/bug.php?id=52939&edit=1 ID: 52939 Patch added by: [email protected] Reported by:[email protected] Summary:zend_call_function does not respect ZEND_SEND_PREFER_REF Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Block user comment: N New Comment: The following patch has been added/updated: Patch Name: zend_call_user_function_prefer_ref Revision: 1285638612 URL: http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285638612 Previous Comments: [2010-09-28 03:44:24] [email protected] Description: The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it were ZEND_SEND_BY_REF. Test script: --- refcount__gc); php_var_dump(params[i], 0 TSRMLS_CC); } efree(params); } ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3) ZEND_ARG_INFO(0, req_pass_by_val) ZEND_ARG_INFO(1, req_pass_by_ref) ZEND_ARG_INFO(2, req_prefer_ pass_by_ref) ZEND_END_ARG_INFO() Expected result: Both calls would be successful. Actual result: -- Only the direct call is successful: direct call [0x5ddbed0, refcount=1] int(1) [0x5ddc530, refcount=2] &string(1) "a" [0x5ddbf20, refcount=1] int(7) call via zend_call_function PHP Warning: Parameter 3 to test_passing() expected to be a reference, value gi ven in - on line 12 -- Edit this bug report at http://bugs.php.net/bug.php?id=52939&edit=1
Bug #52939 [PATCH]: zend_call_function does not respect ZEND_SEND_PREFER_REF
Edit report at http://bugs.php.net/bug.php?id=52939&edit=1 ID: 52939 Patch added by: [email protected] Reported by:[email protected] Summary:zend_call_function does not respect ZEND_SEND_PREFER_REF Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Block user comment: N New Comment: The following patch has been added/updated: Patch Name: zend_call_user_function_prefer_ref Revision: 1285639039 URL: http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285639039 Previous Comments: [2010-09-28 03:50:12] [email protected] The following patch has been added/updated: Patch Name: zend_call_user_function_prefer_ref Revision: 1285638612 URL: http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285638612 [2010-09-28 03:44:24] [email protected] Description: The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it were ZEND_SEND_BY_REF. Test script: --- refcount__gc); php_var_dump(params[i], 0 TSRMLS_CC); } efree(params); } ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3) ZEND_ARG_INFO(0, req_pass_by_val) ZEND_ARG_INFO(1, req_pass_by_ref) ZEND_ARG_INFO(2, req_prefer_ pass_by_ref) ZEND_END_ARG_INFO() Expected result: Both calls would be successful. Actual result: -- Only the direct call is successful: direct call [0x5ddbed0, refcount=1] int(1) [0x5ddc530, refcount=2] &string(1) "a" [0x5ddbf20, refcount=1] int(7) call via zend_call_function PHP Warning: Parameter 3 to test_passing() expected to be a reference, value gi ven in - on line 12 -- Edit this bug report at http://bugs.php.net/bug.php?id=52939&edit=1
[PHP-BUG] Bug #52940 [NEW]: call_user_func_array still allows call-time pass-by-reference
From: cataphract Operating system: Windows 7 x64; Debian Lenny x64 PHP version: trunk-SVN-2010-09-28 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:call_user_func_array still allows call-time pass-by-reference Description: zend_call_function does not properly convert references into non-references, hence allowing passing by reference arguments to functions that expect values. See also bug #43484. This is harder to do with internal function because there's currently a variable separation for those. However, it's still not impossible, because if I'm not mistaken there are ways to make the engine give you a variable with is_ref = 1, refcount <= 1. I propose making the behavior for internal functions consistent with that of user functions by separating the variable all time if it's a reference and the parameter is to be sent by value; for cases where is_ref = 1, refcount <= 1, the reference flag should be cleared. Test script: --- http://bugs.php.net/bug.php?id=52940&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52940&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52940&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52940&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52940&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52940&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52940&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52940&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52940&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52940&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52940&r=support Expected behavior: http://bugs.php.net/fix.php?id=52940&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52940&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52940&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52940&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52940&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52940&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52940&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52940&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52940&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52940&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52940&r=mysqlcfg
Bug #52940 [PATCH]: call_user_func_array still allows call-time pass-by-reference
Edit report at http://bugs.php.net/bug.php?id=52940&edit=1 ID: 52940 Patch added by: [email protected] Reported by:[email protected] Summary:call_user_func_array still allows call-time pass-by-reference Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64; Debian Lenny x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Block user comment: N New Comment: The following patch has been added/updated: Patch Name: no_call_time_pass_by_ref_via_ZCF Revision: 1285649367 URL: http://bugs.php.net/patch-display.php?bug=52940&patch=no_call_time_pass_by_ref_via_ZCF&revision=1285649367 Previous Comments: [2010-09-28 04:53:54] [email protected] Description: zend_call_function does not properly convert references into non-references, hence allowing passing by reference arguments to functions that expect values. See also bug #43484. This is harder to do with internal function because there's currently a variable separation for those. However, it's still not impossible, because if I'm not mistaken there are ways to make the engine give you a variable with is_ref = 1, refcount <= 1. I propose making the behavior for internal functions consistent with that of user functions by separating the variable all time if it's a reference and the parameter is to be sent by value; for cases where is_ref = 1, refcount <= 1, the reference flag should be cleared. Test script: --- http://bugs.php.net/bug.php?id=52940&edit=1
Bug #52944 [PATCH]: fclose: quiet script interruption
Edit report at http://bugs.php.net/bug.php?id=52944&edit=1 ID: 52944 Patch added by: [email protected] Reported by:svimik at mail dot ru Summary:fclose: quiet script interruption Status: Verified Type: Bug Package:*Network Functions Operating System: Debian-50-lenny-64 PHP Version:5.3.3 Block user comment: N New Comment: The following patch has been added/updated: Patch Name: zlib_filter_segfault_fix Revision: 1285725279 URL: http://bugs.php.net/patch-display.php?bug=52944&patch=zlib_filter_segfault_fix&revision=1285725279 Previous Comments: [2010-09-28 22:10:55] [email protected] Valgrind log for trunk: http://nebm.ist.utl.pt/~glopes/valgrind-52944.log [2010-09-28 21:58:55] [email protected] I can confirm some sort of bug in both PHP 5.3.3 and trunk on Debian Lenny x64. On trunk: [Tue Sep 28 20:54:06 2010] Script: '-' --- /tmp/trunk/ext/zlib/zlib_filter.c(165) : Block 0x7fba5a6120c0 status: Beginning: OK (allocated on /tmp/trunk/ext/zlib/zlib_filter.c:311, 2048 bytes) Start: OK End: Overflown (magic=0x0018 instead of 0x5289A744) At least 4 bytes overflown --- done [Tue Sep 28 20:54:06 2010] Script: '-' /tmp/trunk/ext/zlib/zlib_filter.c(311) : Freeing 0x7FBA5A6120C0 (2048 bytes), script=- === Total 1 memory leaks detected === On PHP 5.3.3 (sorry, not debug build), there's a segfault: #0 zend_mm_remove_from_free_list (heap=0x11fc290, mm_block=0x1407380) at /opt/php-5.3.3/Zend/zend_alloc.c:841 #1 0x0069613e in _zend_mm_free_int (heap=0x11fc290, p=0x1406b80) at /opt/php-5.3.3/Zend/zend_alloc.c:2019 #2 0x7f029fa548c9 in php_zlib_inflate_dtor ( thisfilter=) at /opt/php-5.3.3/ext/zlib/zlib_filter.c:161 #3 0x00678ae2 in php_stream_filter_free (filter=0x1409950) at /opt/php-5.3.3/main/streams/filter.c:312 #4 0x00678b8a in php_stream_filter_remove (filter=0x0, call_dtor=1) at /opt/php-5.3.3/main/streams/filter.c:531 #5 0x0067559a in _php_stream_free (stream=0x14096a0, close_options=11) at /opt/php-5.3.3/main/streams/streams.c:369 #6 0x006757d1 in stream_resource_regular_dtor ( rsrc=) at /opt/php-5.3.3/main/streams/streams.c:1426 #7 0x006c34a2 in list_entry_destructor (ptr=0x14097e0) at /opt/php-5.3.3/Zend/zend_list.c:184 #8 0x006c2566 in zend_hash_del_key_or_index (ht=0xc6e7b0, arKey=0x0, nKeyLength=0, h=2, flag=) at /opt/php-5.3.3/Zend/zend_hash.c:497 #9 0x006c3719 in _zend_list_delete (id=) at /opt/php-5.3.3/Zend/zend_list.c:58 #10 0x005fbd88 in zif_fclose (ht=, return_value=0x1409228, return_value_ptr=, this_ptr=, return_value_used=) at /opt/php-5.3.3/ext/standard/file.c:928 #11 0x00704cce in zend_do_fcall_common_helper_SPEC ( execute_data=0x7f029f9ce050) at /opt/php-5.3.3/Zend/zend_vm_execute.h:316 #12 0x006e0589 in execute (op_array=0x14067c8) at /opt/php-5.3.3/Zend/zend_vm_execute.h:107 #13 0x006b349b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /opt/php-5.3.3/Zend/zend.c:1194 #14 0x0065e5e8 in php_execute_script (primary_file=0x7fff04d51350) at /opt/php-5.3.3/main/main.c:2260 #15 0x00740717 in main (argc=1, argv=0x7fff04d515b8) at /opt/php-5.3.3/sapi/cli/php_cli.c:1192 [2010-09-28 21:40:50] svimik at mail dot ru Description: Don't know exactly, is it bug in zlib filter or in streams, but this combination can produce a script crash without any error output. Lets take some binary data like corrupted compressed data (not every random data produce crash, so try file from my example). Use stream_socket_pair with zlib.inflate filter on the second socket, which is used for reading in my case. Use non-blocking streams. Then make exactly following sequence to produce crash: 1. write corrupted data to socket 0 2. call fread for socket 1 (returns nothing as expected, because string cannot be uncompressed) 3. call fclose for socket 0 4. try fread for socket 1 once again 5. call fclose for socket 1 - on this step scrips dies. Sorry, can't make a backtrace on a production server, because it is necessary to recompile the php. Waiting for someone to confirm the bug. Test script: --- http://188.40.74.4/corrupted.gz";); $out=""; fwrite($sockets[0], $in); $out.=fread($sockets[1], 1); fclose($sockets[0]); $out.=fread($sockets[1], 1); echo "closing..."; fclose($sockets[1])
Bug #51986 [PATCH]: array_filter breaks references when a callback is used
Edit report at http://bugs.php.net/bug.php?id=51986&edit=1 ID: 51986 Patch added by: [email protected] Reported by:daniel dot menard at ehesp dot fr Summary:array_filter breaks references when a callback is used Status: Analyzed Type: Bug Package:Arrays related Operating System: Windows XP PHP Version:5.3.2 Assigned To:dmitry Block user comment: N New Comment: The following patch has been added/updated: Patch Name: bug_51986_5_3 Revision: 1285794735 URL: http://bugs.php.net/patch-display.php?bug=51986&patch=bug_51986_5_3&revision=1285794735 Previous Comments: [2010-09-29 23:11:41] [email protected] Sorry, it doesn't work on trunk, it works on my patched trunk :p Fixing bug #52940 would fix this. However, the patch for that bug has one effect that changes the current behavior of call_user_func_array (removes check for internal function) and another change when the refcount of the zval is <= 1 and it's a reference (a rare case). Attached a patch that changes as little as possible, yet fixes this bug. ---- [2010-09-29 13:05:51] [email protected] Reproducible on PHP 5.3, but not on trunk. [2010-06-03 14:29:38] daniel dot menard at ehesp dot fr Thanks for your comment: your workaround works. However, having to redefine standard php functions like trim() or count() just to be able to use them with array_filter() is not very convenient, is it? The fact is that the function behaviour changed in a "revision release" which should not have broken my code... ;-) [2010-06-03 13:00:43] [email protected] Use a reference in your callback function: function my_trim(& $a) { return trim($a); } [2010-06-03 12:28:24] daniel dot menard at ehesp dot fr Description: I have an array and a variable which is a reference on some element in this array: $arr=array('a'); $ref = &$arr[0] If I apply array_filter() with a callback like trim() or count() on the array, the reference is broken and $ref is no longer a reference (If I apply array_filter() without a callback, the reference is not altered and the result is correct). I think that this is a regression introduced in php 5.2.11: with the test script below, 5.2.10 give the good result, 5.2.11 do not. I also tested with the latest version (5.3.2): same result, reference is broken. PS: I tested on windows XP with packages php-5.x.y-Win32-VC6-x86.zip provided on this page: http://windows.php.net/downloads/releases/archives/ Test script: --- // Init $arr = array('some value'); $ref = & $arr[0]; // Change $arr $arr[0] = 'ONE'; echo 'step 1. $ref is ', ($ref !== 'ONE') ? 'BROKEN' : 'OK', "\n"; // Apply array_filter (without callback) and change $arr array_filter($arr); $arr[0] = 'TWO'; echo 'step 2. $ref is ', ($ref !== 'TWO') ? 'BROKEN' : 'OK', "\n"; // Apply array_filter (with a callback) then change $arr array_filter($arr,'trim'); $arr[0] = 'THREE'; echo 'step 3. $ref is ', ($ref !== 'THREE') ? 'BROKEN' : 'OK', "\n"; Expected result: step 1. $ref is OK step 2. $ref is OK step 3. $ref is OK Actual result: -- step 1. $ref is OK step 2. $ref is OK step 3. $ref is BROKEN -- Edit this bug report at http://bugs.php.net/bug.php?id=51986&edit=1
[PHP-BUG] Bug #53012 [NEW]: On shared module unload: Unloading DLL containing an active critical section.
From: cataphract Operating system: Vista amd64 PHP version: trunk-SVN-2010-10-07 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:On shared module unload: Unloading DLL containing an active critical section. Description: When running PHP with App verifier, there's an exception on module unload. Test script: --- This happens with an empty script Expected result: No exception. Actual result: -- CommandLine: C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php.exe Symbol search path is: SRV*C:\Users\Cataphract\AppData\Local\SYMBOLS*http://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: `0040 `00421000 php.exe ModLoad: `7795 `77ad6000 ntdll.dll ModLoad: `77b1 `77c7 ntdll32.dll ModLoad: `7526 `752a5000 C:\Windows\system32\wow64.dll ModLoad: `7521 `7525e000 C:\Windows\system32\wow64win.dll ModLoad: `753e `753e9000 C:\Windows\system32\wow64cpu.dll (2e40.3150): Break instruction exception - code 8003 (first chance) ntdll!DbgBreakPoint: `77996060 cc int 3 0:000> g ModLoad: `7732 `7744d000 WOW64_IMAGE_SECTION ModLoad: `76a4 `76b5 WOW64_IMAGE_SECTION ModLoad: `7732 `7744d000 NOT_AN_IMAGE ModLoad: `7725 `7731d000 NOT_AN_IMAGE ModLoad: `71ab `71ae1000 C:\Windows\syswow64\verifier.dll Page heap: pid 0x2E40: page heap enabled with flags 0x3. AVRF: php.exe: pid 0x2E40: flags 0x80C43027: application verifier enabled ModLoad: `7213 `72159000 C:\Windows\SysWOW64\vrfcore.dll ModLoad: `7190 `71951000 C:\Windows\SysWOW64\vfbasics.dll ModLoad: `76a4 `76b5 C:\Windows\syswow64\kernel32.dll ModLoad: `1000 `106b9000 C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php5ts_debug.dll ModLoad: `76f2 `77065000 C:\Windows\syswow64\ole32.dll ModLoad: `7714 `771ea000 C:\Windows\syswow64\msvcrt.dll ModLoad: `76b5 `76be C:\Windows\syswow64\GDI32.dll ModLoad: `7563 `7570 C:\Windows\syswow64\USER32.dll ModLoad: `7707 `77136000 C:\Windows\syswow64\ADVAPI32.dll ModLoad: `76e0 `76ef C:\Windows\syswow64\RPCRT4.dll ModLoad: `755a `7560 C:\Windows\syswow64\Secur32.dll ModLoad: `76ef `76f1d000 C:\Windows\syswow64\WS2_32.dll ModLoad: `77ae `77ae6000 C:\Windows\syswow64\NSI.dll ModLoad: `74ce `74d0c000 C:\Windows\SysWOW64\DNSAPI.dll ModLoad: `7198 `71aa4000 C:\Windows\WinSxS\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_2a4cbfc25558bcd3\MSVCR90D.dll (2e40.3150): WOW64 breakpoint - code 401f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ntdll32!DbgBreakPoint: 77b20004 cc int 3 0:000:x86> g ModLoad: 771f 7725 C:\Windows\SysWOW64\IMM32.DLL ModLoad: 75ba 75c68000 C:\Windows\syswow64\MSCTF.dll ModLoad: 76df 76df9000 C:\Windows\syswow64\LPK.DLL ModLoad: 75eb 75f2d000 C:\Windows\syswow64\USP10.dll ModLoad: 751d 7520b000 C:\Windows\SysWOW64\rsaenh.dll ModLoad: 74d7 74d8e000 C:\Windows\SysWOW64\USERENV.dll ModLoad: 01d3 01d96000 C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php_intl.dll ModLoad: 4a80 4a925000 C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icuuc42.dll ModLoad: 4ad0 4bc48000 C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icudt42.dll ModLoad: 7135 713f3000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb\MSVCR90.dll ModLoad: 712c 7134e000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb\MSVCP90.dll ModLoad: 06c1 06d69000 C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icuin42.dll === VERIFIER STOP 0201: pid 0x2E40: Unloading DLL containing an active critical section. 4A91D150 : Critical section address. 00C418C0 : Critical section initialization stack trace. 04F56FE8 : DLL name address. 4A80 : DLL base address. === This verifier stop is continuable. After debugging it use `go' to continue. === (2e40.3150): WOW64 breakpoint - code 401f (first
[PHP-BUG] Bug #53013 [NEW]: Memory leak detected when compiled with --enable-crt-debug
From: cataphract
Operating system: Vista amd64
PHP version: trunk-SVN-2010-10-07 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Memory leak detected when compiled with --enable-crt-debug
Description:
An empty script causes a memory leak that is detected when PHP is compiled
with --enable-crt-debug.
Test script:
---
This happens with an empty script.
Actual result:
--
Detected memory leaks!
Dumping objects ->
#File Error#(641) : {7774} normal block at 0x09CECFF0, 6 bytes long.
Data: 70 74 5F 50 54 00
Object dump complete.
--
Edit bug report at http://bugs.php.net/bug.php?id=53013&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53013&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53013&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53013&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53013&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53013&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53013&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53013&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53013&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53013&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53013&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53013&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53013&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53013&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53013&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53013&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53013&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53013&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53013&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53013&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53013&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53013&r=mysqlcfg
Req #44164 [Com]: Handle "Content-Length" HTTP header when zlib.output_compression active
Edit report at http://bugs.php.net/bug.php?id=44164&edit=1 ID: 44164 Comment by: [email protected] Reported by:mplomer at gmx dot de Summary:Handle "Content-Length" HTTP header when zlib.output_compression active Status: Assigned Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:5.2.5 Assigned To:cataphract Block user comment: N New Comment: I've just been hit by this problem and I'm thinking a better option would be to disable zlib.output_compression if the Content-Length header is set. What do you think? Buffering everything and then calculating the actual length is not really an option, the output could be several hundred megabytes. Previous Comments: [2008-02-19 11:04:24] mplomer at gmx dot de Another idea is: IF the Content-Length header IS set from the script, THEN buffer the complete output and calculate the correct compressed Content-Length. ELSE do nothing (do not add any Content-Length header) So ob_flush(), flush() will still work if compression is active. (Which will not work, if we use apache's mod_deflate. This is why "zlib.output_compression" is required.) [2008-02-19 10:48:09] mplomer at gmx dot de Description: If you have a big project, where "Content-Length" header is set on many places, and then you turn on "zlib.output_compression", you will have a problem, because the original header is still passed through, but it is invalid now, because it contains the length of the uncompressed data instead of the compressed data. This would confuse some HTTP clients, that rely on the "Content-Length". I think, "zlib.output_compression" should be completely transparent, so this issue should be handled in php core. One solution is, to remove the "Content-Length" header (if set) in ob_gzhandler() in ext/zlib/zlib.c:882 (where "Content-Encoding: gzip" header is set). If you see a good way to set the Content-Length to the compressed length, this would be, of course, the best solution, but this is IMHO only possible, if the entire data is buffered before (or is this done by ob_gzhandler anyway?). This would make the various workarounds irrelevant that have to be done if "zlib.output_compression" is active and is completely backward compatible. Reproduce code: --- In php.ini: zlib.output_compression = On Expected result: Correct "Content-Length" header or removed "Content-Length" header in response, because the old length is always wrong. Better send no "Content-Length" instead a wrong length. Actual result: -- The old "Content-Length" header is sent. -- Edit this bug report at http://bugs.php.net/bug.php?id=44164&edit=1
[PHP-BUG] Bug #53153 [NEW]: Memory leak with phpinfo() + output buffering + zlib compression
From: cataphract
Operating system: Windows 7 x64
PHP version: trunk-SVN-2010-10-25 (SVN)
Package: Output Control
Bug Type: Bug
Bug description:Memory leak with phpinfo() + output buffering + zlib compression
Description:
There is a memory leak on memory allocated on \main\output.c(809):
if ((handler->buffer.size - handler->buffer.used) <= buf->used)
{
size_t grow_int =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);
size_t grow_buf =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));
size_t grow_max = MAX(grow_int, grow_buf);
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */
handler->buffer.size += grow_max;
}
phpinfo() code:
/* Andale! Andale! Yee-Hah! */
php_output_start_default(TSRMLS_C);
php_print_info(flag TSRMLS_CC);
php_output_end(TSRMLS_C);
Test script:
---
File file.php
---
http://bugs.php.net/bug.php?id=53153&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53153&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53153&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53153&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53153&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53153&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53153&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53153&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53153&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53153&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53153&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53153&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53153&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53153&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53153&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53153&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53153&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53153&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53153&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53153&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53153&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53153&r=mysqlcfg
Bug #53153 [Com]: Memory leak with phpinfo() + output buffering + zlib compression
Edit report at http://bugs.php.net/bug.php?id=53153&edit=1 ID: 53153 Comment by: [email protected] Reported by:[email protected] Summary:Memory leak with phpinfo() + output buffering + zlib compression Status: Open Type: Bug Package:Output Control Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-10-25 (SVN) Block user comment: N New Comment: Note: there seems to be no leak if the environment variables HTTP_ACCEPT_ENCODING actually triggers the zlib compression. Previous Comments: [2010-10-25 19:26:56] [email protected] Interestingly there's also some corrupted/uninitialized memory in the memory leak message: [Mon Oct 25 18:19:39 2010] Script: 'z8ââ¥⥥?dâ�...@à âº' c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing 0x012B0088 ( 49152 bytes), script=z8ââ¥⥥?dâ�...@Ã⺠=== Total 1 memory leaks detected === [2010-10-25 19:25:44] [email protected] Description: There is a memory leak on memory allocated on \main\output.c(809): if ((handler->buffer.size - handler->buffer.used) <= buf->used) { size_t grow_int = PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size); size_t grow_buf = PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used - (handler->buffer.size - handler->buffer.used)); size_t grow_max = MAX(grow_int, grow_buf); handler->buffer.data = erealloc(handler->buffer.data, handler->buffer.size + grow_max); /* memory was allocated here */ handler->buffer.size += grow_max; } phpinfo() code: /* Andale! Andale! Yee-Hah! */ php_output_start_default(TSRMLS_C); php_print_info(flag TSRMLS_CC); php_output_end(TSRMLS_C); Test script: --- File file.php --- http://bugs.php.net/bug.php?id=53153&edit=1
[PHP-BUG] Bug #53172 [NEW]: ZEND_ACC_IMPLICIT_PUBLIC should be removed or used in zend_get_property_info
From: cataphract Operating system: PHP version: 5.3SVN-2010-10-26 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:ZEND_ACC_IMPLICIT_PUBLIC should be removed or used in zend_get_property_info Description: The status of the flag ZEND_ACC_IMPLICIT_PUBLIC is somewhat unclear. In the ZE: * PHP 5.3 checks for it in a few places, but doesn't set it anymore as the body of zend_do_declare_implicit_property is commented out. * trunk retains only the definition of ZEND_ACC_IMPLICIT_PUBLIC, everything else is gone. So it seems that the flag ZEND_ACC_IMPLICIT_PUBLIC, apparently originally used to signal dynamic properties, is only used by the reflection extension. The reflection extension, not being able to depend on the Zend Engine to set it, sets the flag itself when it finds a dynamic property, i.e. a property that is in the object hash table but has no property_info (ReflectionProperty::__construct and ReflectionClass::getProperty). This would be unnecessary if zend_get_property_info set the flag ZEND_ACC_IMPLICIT_PUBLIC over here: http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_object_handlers.c#310 In that case, the reflection extension could just call zend_get_property_info and not do directly lookups in ce->properties_info. Though right now it would be possible to call zend_get_property_info and check for equality to &EG(property_info), this is suboptimal. -- Edit bug report at http://bugs.php.net/bug.php?id=53172&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53172&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53172&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53172&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53172&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53172&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53172&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53172&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53172&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53172&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53172&r=support Expected behavior: http://bugs.php.net/fix.php?id=53172&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53172&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53172&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53172&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53172&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53172&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53172&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53172&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53172&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53172&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53172&r=mysqlcfg
Bug #53199 [PATCH]: Phar doesn't work with '--enable-zend-multibyte' option
Edit report at http://bugs.php.net/bug.php?id=53199&edit=1 ID: 53199 Patch added by: [email protected] Reported by:brt dot river at gmail dot com Summary:Phar doesn't work with '--enable-zend-multibyte' option Status: Open Type: Bug Package:PHAR related Operating System: Mac OS X 10.6 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug53199.patch Revision: 1290066459 URL: http://bugs.php.net/patch-display.php?bug=53199&patch=bug53199.patch&revision=1290066459 Previous Comments: [2010-11-18 07:02:28] php at group dot apple dot com I have been debugging a similar report with the phar CLI. Executing "php phar.php" (using the generated php/ext/phar/phar.php) works properly, but the resulting phar.phar does not. I have tried modifying the stub (via phar.php) to print debugging information but that only produces more "?" characters. Attempting to debug with Xdebug and MacGDBp wouldn't step through the first line before terminating. [2010-10-29 10:22:36] brt dot river at gmail dot com Description: I'm using PHP 5.3.3 with '--enable-zend-multibyte' under Mac OS X. My script calls my phar archive directly, The result characters are garbled. Test script: --- * create.php setStub('http://bugs.php.net/bug.php?id=53199&edit=1
Bug #53465 [PATCH]: Cannot open file descriptor streams
Edit report at http://bugs.php.net/bug.php?id=53465&edit=1 ID: 53465 Patch added by: [email protected] Reported by:dchurch at sciencelogic dot com Summary:Cannot open file descriptor streams Status: Open Type: Bug Package:Filesystem function related Operating System: Linux PHP Version:5.3.3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php_fd_open.diff Revision: 1291674246 URL: http://bugs.php.net/patch-display.php?bug=53465&patch=php_fd_open.diff&revision=1291674246 Previous Comments: [2010-12-03 18:24:11] dchurch at sciencelogic dot com Description: PHP cannot open, read from, or write to arbitrary file descriptors, a feature that is necessary for communications with certain utilities that expect input or output on certain file descriptors. When programming in C, this functionality is provided by fdopen(). A feature request was filed over seven years ago for PHP to have a similar capability through the php:// stream wrapper (#26158), but the bug was marked as bogus for no adequately defined reason. The alternative to being able to use a fdopen()-like function is to open the file descriptor as a named file through /dev/fd/ or /proc/self/fd/. This works in C using fopen("/dev/fd/", "w"), but it does not work in PHP because PHP incorrectly attempts to dereference the pseudo-symlink before opening it. I have a C program and a PHP script that both attempt to do the same thing: open file descriptor 3 for writing using /dev/fd/3, read until EOF from standard in and write to the file descriptor. Both should be run as: (executable) 3>&1 | cat Test script: --- PHP script: int main() { char buf[8192]; int count; FILE *file; file = fopen("/dev/fd/3", "w"); if (file == NULL) { perror("Opening /dev/fd/3"); return 1; } while ((count = fread(buf, 1, sizeof(buf), stdin)) > 0) { fwrite(buf, count, 1, file); if (feof(stdin)) break; } return 0; } Expected result: Input should be mirrored to file descriptor 3; when called using the command line above, it should be mirrored to standard output. Actual result: -- I get the following warning: PHP Warning: fopen(/dev/fd/3): failed to open stream: No such file or directory in test.php on line 2 An strace of the PHP process shows the incorrect behavior: lstat("/dev/fd/3", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0 readlink("/dev/fd/3", "pipe:[637257]", 4096) = 13 lstat("/dev/fd/pipe:[637257]", 0x7fff76ae8140) = -1 ENOENT (No such file or directory) lstat("/dev/fd", {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0 readlink("/dev/fd", "/proc/self/fd"..., 4096) = 13 lstat("/proc/self/fd", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0 lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=64, ...}) = 0 readlink("/proc/self", "28234"..., 4096) = 5 lstat("/proc/28234", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 open("/proc/28234/fd/pipe:[637257]", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) -- Edit this bug report at http://bugs.php.net/bug.php?id=53465&edit=1
Bug #54440 [PATCH]: stream_context_set_default() should publish the default context to everybody
Edit report at http://bugs.php.net/bug.php?id=54440&edit=1 ID: 54440 Patch added by: [email protected] Reported by:[email protected] Summary:stream_context_set_default() should publish the default context to everybody Status: Open Type: Bug Package:Streams related Operating System: *nix PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: libxslt_54440.patch Revision: 1301869965 URL: http://bugs.php.net/patch-display.php?bug=54440&patch=libxslt_54440.patch&revision=1301869965 Previous Comments: [2011-04-01 11:45:40] [email protected] See also #52926 [2011-04-01 11:43:32] [email protected] Description: stream_context_set_default() doesn't publish the context to all PHP extension. Example is ext/libxml that doesn't recognize the context. Test script: --- stream_context_set_default(array('http'=>array('proxy'=>'my_proxy_url'))); $x = simplexml_load_file('http://some_resource'); Expected result: The resource gets loaded through the HTTP proxy Actual result: -- The resource is not loaded through the HTTP proxy. For this to work, we have to use : $ctx = stream_context_create(array('http'=>array('proxy'=>'my_proxy_url'))); libxml_set_streams_context($ctx); // userland manual bind $x = simplexml_load_file('http://some_resource'); -- Edit this bug report at http://bugs.php.net/bug.php?id=54440&edit=1
Bug #54547 [PATCH]: wrong equality of string numbers
Edit report at http://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Patch added by: [email protected] Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug54547.diff Revision: 1302998399 URL: http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547.diff&revision=1302998399 Previous Comments: [2011-04-16 20:07:43] peter dot ritt at gmx dot net Description: comparison of strings using == shows wrong results when both strings are numbers (digits) around PHP_MAX_INT; the same comparison using === works correctly; tested on 64 bit systems only, affects also PHP 5.3.5 Test script: --- $a = '9223372036854775807'; $b = '9223372036854775808'; if ($a == $b) { echo "$a == $b\n"; } else { echo "$a != $b\n"; } // displays 9223372036854775807 == 9223372036854775808 Expected result: should display 9223372036854775807 != 9223372036854775808 Actual result: -- displays 9223372036854775807 == 9223372036854775808 -- Edit this bug report at http://bugs.php.net/bug.php?id=54547&edit=1
Bug #54547 [PATCH]: wrong equality of string numbers
Edit report at http://bugs.php.net/bug.php?id=54547&edit=1 ID: 54547 Patch added by: [email protected] Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug54547-2.diff Revision: 1303011843 URL: http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547-2.diff&revision=1303011843 Previous Comments: [2011-04-17 01:59:59] [email protected] The following patch has been added/updated: Patch Name: bug54547.diff Revision: 1302998399 URL: http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547.diff&revision=1302998399 [2011-04-16 20:07:43] peter dot ritt at gmx dot net Description: comparison of strings using == shows wrong results when both strings are numbers (digits) around PHP_MAX_INT; the same comparison using === works correctly; tested on 64 bit systems only, affects also PHP 5.3.5 Test script: --- $a = '9223372036854775807'; $b = '9223372036854775808'; if ($a == $b) { echo "$a == $b\n"; } else { echo "$a != $b\n"; } // displays 9223372036854775807 == 9223372036854775808 Expected result: should display 9223372036854775807 != 9223372036854775808 Actual result: -- displays 9223372036854775807 == 9223372036854775808 -- Edit this bug report at http://bugs.php.net/bug.php?id=54547&edit=1
Bug #54580 [PATCH]: get_browser() segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54580&edit=1 ID: 54580 Patch added by: [email protected] Reported by:tomas dot brastavicius at quantum dot lt Summary:get_browser() segmentation fault Status: Assigned Type: Bug Package:Unknown/Other Function Operating System: Ubuntu 10.10 (x86_64) PHP Version:trunk-SVN-2011-04-20 (SVN) Assigned To:cataphract Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: browscap.diff Revision: 1303783306 URL: http://bugs.php.net/patch-display.php?bug=54580&patch=browscap.diff&revision=1303783306 Previous Comments: [2011-04-21 13:54:12] [email protected] The problem is not ini_set, the segault occurs because PHP assumes the parse result of the code is initialized when the ini setting is non-empty; however, by using php_admin_value, the ini setting value is set after when the parsing code runs, so when it runs it leaves memory initialized because the ini setting is empty. This should be fixed by having the ini setting change via php_admin_value trigger the ini reading and structure initialization. [2011-04-21 00:06:11] tomas dot brastavicius at quantum dot lt Description: PHP is running as an Apache module. The following configuration was used to compile PHP: ./configure --with-apxs2=/usr/bin/apxs2 --enable-debug --disable-all Test script: --- 1. Be sure browscap directive is commented out in php.ini 2. Set browscap setting in Apache configuration file, i.e. php_admin_value browscap "/some/path/browscap.ini" 3. Run the following PHP script: arBuckets[nIndex]; Full backtrace: #0 0x709db2af in zend_hash_find (ht=0x70e6e100, arKey=0x77f6b760 "User-Agent", nKeyLength=109, pData=0x7fffbdb8) at /a/php-trunk/Zend/zend_hash.c:905 #1 0x708ac3b1 in zif_get_browser (ht=0, return_value=0x77f62be8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /a/php-trunk/ext/standard/browscap.c:360 #2 0x70a09972 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f2e338) at /a/php-trunk/Zend/zend_vm_execute.h:642 #3 0x70a0ffd2 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x77f2e338) at /a/php-trunk/Zend/zend_vm_execute.h:1963 #4 0x70a08077 in execute (op_array=0x77f611c0) at /a/php-trunk/Zend/zend_vm_execute.h:410 #5 0x709c88a3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /a/php-trunk/Zend/zend.c:1212 #6 0x70933982 in php_execute_script (primary_file=0x7fffe670) at /a/php-trunk/main/main.c:2349 #7 0x70b0de48 in php_handler (r=0x784bbea0) at /a/php-trunk/sapi/apache2handler/sapi_apache2.c:667 #8 0x77fd6310 in ap_run_handler (r=0x784bbea0) at /build/buildd/apache2-2.2.16/server/config.c:159 #9 0x77fd9c9e in ap_invoke_handler (r=0x784bbea0) at /build/buildd/apache2-2.2.16/server/config.c:377 #10 0x77fe77b8 in ap_process_request (r=0x784bbea0) at /build/buildd/apache2-2.2.16/modules/http/http_request.c:282 #11 0x77fe4748 in ap_process_http_connection (c=0x784adc90) at /build/buildd/apache2-2.2.16/modules/http/http_core.c:190 #12 0x77fddef8 in ap_run_process_connection (c=0x784adc90) at /build/buildd/apache2-2.2.16/server/connection.c:43 #13 0x77fec177 in child_main (child_num_arg=) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:662 #14 0x77fec446 in make_child (s=0x78214938, slot=0) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:702 #15 0x77feca93 in ap_mpm_run (_pconf=, plog=, s=) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:978 #16 0x77fc2530 in main (argc=2, argv=0x7fffecf8) at /build/buildd/apache2-2.2.16/server/main.c:742 -- Edit this bug report at http://bugs.php.net/bug.php?id=54580&edit=1
[PHP-BUG] Bug #54657 [NEW]: Function parameters can no longer be named after superglobal variables
From: cataphract Operating system: Any PHP version: trunk-SVN-2011-05-04 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Function parameters can no longer be named after superglobal variables Description: There is a backwards incompatible change in trunk in that function can no longer have parameters with a name equal to the one of some superglobal. This should either be fixed with the previous behavior (the parameter shadows the superglobal) or documented in UPGRADING. Test script: --- $ php -d error_reporting=-1 http://bugs.php.net/bug.php?id=54657&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54657&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54657&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54657&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54657&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54657&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54657&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54657&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54657&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54657&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54657&r=support Expected behavior: http://bugs.php.net/fix.php?id=54657&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54657&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54657&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54657&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54657&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54657&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54657&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54657&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54657&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54657&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54657&r=mysqlcfg
[PHP-BUG] Bug #60007 [NEW]: comparison function is not anticommutative for arrays claimed to be comparable
From: cataphract
Operating system: Irrelevant
PHP version: trunk-SVN-2011-06-29 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:comparison function is not anticommutative for arrays claimed
to be comparable
Description:
This discussion is limited to the subsets of the array domain with elements
that the manual claims are comparable between each other:
«Array with fewer members is smaller, if key from operand 1 is not found
in operand 2 then arrays are uncomparable, otherwise - compare value by
value»
http://docs.php.net/manual/en/language.operators.comparison.php
Whether the relations should be total (or partial) orders in the entire
array domain is beyond the scope of this bug report.
The comparison function used to compare arrays with the operators, <, <=,
>, >= is not anticommutative, i.e., swapping the arguments doesn't change
the sign. It should be the case that
cmp(a, b) = - cmp(b, a)
The reason for this is that the relations <, <=, >, >= should be
antisymmetric, i.e., R(a, b) and R(b, a) cannot both be true unless maybe a
== b (in which case the relation is reflexive, as is the case of <= and
>=).
The relationship between the comparison function and the relations easily
follows by how the relations are defined:
a < b === cmp(a,b) == -1
a <= b === cmp(a,b) <= 0
a > b === cmp(b,a) == -1
a >= b === cmp(b,a) <= 0
It is important that the relations are antisymmetric because it's a
requirement for relation to be a total (or even partial!) order. Without
that property, it's impossible to, for instance, reliably sort or do a
binary search in an array of arrays.
The problem is the comparison function is sensitive to the order of the
arguments. It starts by comparing the value of the first element of the
first operand with the corresponding (i.e., with the same key) element in
the second operand. One can see that, for any two arrays with the same
length and keys, if reset($a) < $b[key($a)] && reset($b) < $x[key($a)],
then $a < $b and $b < $a.
References:
http://en.wikipedia.org/wiki/Anticommutativity
http://en.wikipedia.org/wiki/Antisymmetric_relation
http://en.wikipedia.org/wiki/Reflexive_relation
http://en.wikipedia.org/wiki/Total_order
http://stackoverflow.com/questions/6480365/comparing-arrays-in-php-interesting-behaviour/6481181#6481181
Test script:
---
1, "b" => 2);
$a = array("b" => 1, "a" => 2);
var_dump($a < $b);
var_dump($b < $a);
var_dump($b > $a);
var_dump($a > $b);
Expected result:
bool(true) //or false
bool(false) //or true
bool(true) //or false
bool(false) //or true
Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
--
Edit bug report at https://bugs.php.net/bug.php?id=60007&edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=60007&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60007&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60007&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60007&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60007&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60007&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60007&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60007&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60007&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60007&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60007&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60007&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60007&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60007&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60007&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60007&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60007&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60007&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60007&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60007&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60007&r=mysqlcfg
Bug #55305 [PATCH]: ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating
Edit report at https://bugs.php.net/bug.php?id=55305&edit=1 ID: 55305 Patch added by: [email protected] Reported by:[email protected] Summary:ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating Status: Open Type: Bug Package:*General Issues Operating System: ALL PHP Version:5.4SVN-2011-07-27 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug55305.patch Revision: 1311813002 URL: https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813002 Previous Comments: [2011-07-27 23:32:55] [email protected] Description: Reference is lost, causing segfault and/or oddities when primary reference is edited after secondary is edited. Occurs only when the variable name is instantiated in the class definition, and the second reference is not instantiated before it is made. Possible workarounds include: Instantiate neither variable name in the class definition Instantiate both variable names in the class definition Instantiate secondary variable name before making it a reference to the first: $this->bar = nil; $this->bar =& $this->foo; The bug is new to 5.4. Test script: --- foo = ''; $this->bar =& $this->foo; } function dump(){ echo 'foo: ';var_dump($this->foo); echo 'bar: ';var_dump($this->bar); } } $f = new Foo(); $f->dump(); $f->foo .= 'foo'; $f->dump(); $f->bar .= 'bar'; $f->dump(); $f->foo .= 'foo'; $f->dump(); ?> Expected result: foo: string(0) "" bar: string(0) "" foo: string(3) "bar" bar: string(3) "bar" foo: string(6) "barfoo" bar: string(6) "barfoo" Actual result: -- varies from platform to platform On Windows: foo: string(0) "" bar: NULL foo: string(3) "foo" bar: NULL foo: UNKNOWN:0 bar: string(3) "bar" CRASH On Linux (Ubuntu 11.04): foo: string(0) "" bar: NULL foo: NULL bar: string(3) "bar" foo: string(3) "foo" bar: string(3) "???" where ?? is 3 seemingly-random bytes. OR, if an additional one-or-three-parameter method is defined in the class (even if it is not called): string(0) "" NULL NULL Segmentation fault If the uncalled method has a different number of arguments, it generates a zend_mm_heap_corrupted instead -- Edit this bug report at https://bugs.php.net/bug.php?id=55305&edit=1
Bug #55305 [PATCH]: ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating
Edit report at https://bugs.php.net/bug.php?id=55305&edit=1 ID: 55305 Patch added by: [email protected] Reported by:[email protected] Summary:ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating Status: Open Type: Bug Package:*General Issues Operating System: ALL PHP Version:5.4SVN-2011-07-27 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug55305.patch Revision: 1311813005 URL: https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813005 Previous Comments: [2011-07-28 00:30:02] [email protected] The following patch has been added/updated: Patch Name: bug55305.patch Revision: 1311813002 URL: https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813002 [2011-07-27 23:32:55] [email protected] Description: Reference is lost, causing segfault and/or oddities when primary reference is edited after secondary is edited. Occurs only when the variable name is instantiated in the class definition, and the second reference is not instantiated before it is made. Possible workarounds include: Instantiate neither variable name in the class definition Instantiate both variable names in the class definition Instantiate secondary variable name before making it a reference to the first: $this->bar = nil; $this->bar =& $this->foo; The bug is new to 5.4. Test script: --- foo = ''; $this->bar =& $this->foo; } function dump(){ echo 'foo: ';var_dump($this->foo); echo 'bar: ';var_dump($this->bar); } } $f = new Foo(); $f->dump(); $f->foo .= 'foo'; $f->dump(); $f->bar .= 'bar'; $f->dump(); $f->foo .= 'foo'; $f->dump(); ?> Expected result: foo: string(0) "" bar: string(0) "" foo: string(3) "bar" bar: string(3) "bar" foo: string(6) "barfoo" bar: string(6) "barfoo" Actual result: -- varies from platform to platform On Windows: foo: string(0) "" bar: NULL foo: string(3) "foo" bar: NULL foo: UNKNOWN:0 bar: string(3) "bar" CRASH On Linux (Ubuntu 11.04): foo: string(0) "" bar: NULL foo: NULL bar: string(3) "bar" foo: string(3) "foo" bar: string(3) "???" where ?? is 3 seemingly-random bytes. OR, if an additional one-or-three-parameter method is defined in the class (even if it is not called): string(0) "" NULL NULL Segmentation fault If the uncalled method has a different number of arguments, it generates a zend_mm_heap_corrupted instead -- Edit this bug report at https://bugs.php.net/bug.php?id=55305&edit=1
[PHP-BUG] Bug #55326 [NEW]: Trait method copying misindentifies serialization callbacks
From: cataphract Operating system: Irrelevant PHP version: trunk-SVN-2011-07-31 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Trait method copying misindentifies serialization callbacks Description: _ADD_MAGIC_METHOD in zend_compile.c identifies "serialize_func" and "unserialize_func" as magic methods and copies them to ce->serialize_func and ce->unserialize_func. The correct names are "serialize" and "unserialize". These names could be changed, or, better yet, those two lines should be deleted because the methods serialize and unserialize are only relevant if the class implements Serializable (or, more precisely, if ce->serialize and ce->unserialize are zend_user_serialize and zend_user_unserialize, respectively, and in any case ce->serialize_func and ce->unserialize_func work only as a lazy cache. Test script: --- https://bugs.php.net/bug.php?id=55326&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55326&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55326&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55326&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55326&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55326&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55326&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55326&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55326&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55326&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55326&r=support Expected behavior: https://bugs.php.net/fix.php?id=55326&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55326&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55326&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55326&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55326&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55326&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55326&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55326&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55326&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55326&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55326&r=mysqlcfg
Bug #55326 [PATCH]: Trait method copying misindentifies serialization callbacks
Edit report at https://bugs.php.net/bug.php?id=55326&edit=1 ID: 55326 Patch added by: [email protected] Reported by:[email protected] Summary:Trait method copying misindentifies serialization callbacks Status: Open Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:trunk-SVN-2011-07-31 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug55326.diff Revision: 1312082252 URL: https://bugs.php.net/patch-display.php?bug=55326&patch=bug55326.diff&revision=1312082252 Previous Comments: [2011-07-31 03:16:48] [email protected] Description: _ADD_MAGIC_METHOD in zend_compile.c identifies "serialize_func" and "unserialize_func" as magic methods and copies them to ce->serialize_func and ce->unserialize_func. The correct names are "serialize" and "unserialize". These names could be changed, or, better yet, those two lines should be deleted because the methods serialize and unserialize are only relevant if the class implements Serializable (or, more precisely, if ce->serialize and ce->unserialize are zend_user_serialize and zend_user_unserialize, respectively, and in any case ce->serialize_func and ce->unserialize_func work only as a lazy cache. Test script: --- https://bugs.php.net/bug.php?id=55326&edit=1
[PHP-BUG] Bug #55797 [NEW]: Integer overflow leads to segfault in SdnToGregorian (in optimized builds)
From: cataphract Operating system: Linux/gcc PHP version: 5.3.8 Package: Date/time related Bug Type: Bug Bug description:Integer overflow leads to segfault in SdnToGregorian (in optimized builds) Description: SdnToGregorian has an integer overflow error. This has already been fixed; this report is for reference. See also bug #53574. Test script: --- (x86) php -r 'print_r(cal_from_jd(882858030, CAL_GREGORIAN)); (amd64) php -r 'print_r(cal_from_jd(9223372036854743639, CAL_GREGORIAN));' Expected result: No segfault Actual result: -- Segfault -- Edit bug report at https://bugs.php.net/bug.php?id=55797&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55797&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55797&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55797&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55797&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55797&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55797&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55797&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55797&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55797&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55797&r=support Expected behavior: https://bugs.php.net/fix.php?id=55797&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55797&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55797&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55797&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55797&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55797&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55797&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55797&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55797&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55797&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55797&r=mysqlcfg
Bug #60131 [PATCH]: fopen('php://stdout'...) redirect all posterious echo to /dev/null
Edit report at https://bugs.php.net/bug.php?id=60131&edit=1 ID: 60131 Patch added by: [email protected] Reported by:frederic dot hardy at mageekbox dot net Summary:fopen('php://stdout'...) redirect all posterious echo to /dev/null Status: Wont fix Type: Bug Package:Streams related Operating System: Mac OS Snow Leopard PHP Version:5.3.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60131.diff Revision: 131991 URL: https://bugs.php.net/patch-display.php?bug=60131&patch=bug60131.diff&revision=131991 Previous Comments: [2011-10-30 03:09:23] [email protected] Won't fix since some people rely on this behavior. What happens is the first time you fopen stdout, the file descriptor 1 is not duped and exposed with a stream, instead the stdlib FILE* is exposed through a stream. When the stream is closed, the FILE* is closed too, potentially also closing stdout, i.e., a close(1) syscall (which is what happens in your case â since you don't assign the return of fopen, the stream is immediately destroyed). Turns out some people use this technique to close the standard file descriptors and open others (and AFAIK there's no other way to do it in PHP). [2011-10-25 14:24:53] frederic dot hardy at mageekbox dot net Description: If fopen('php://stdout', ...) is used in a php processus open with proc_open(), all posterious call to echo or print seems to be redirected to /dev/null. Test script: --- array("pipe", "r"), 1 => array("pipe", "w") ); $php = proc_open('php', $descriptors, $pipes); stream_set_blocking($pipes[1], 0); fwrite($pipes[0], ''); fclose($pipes[0]); $null = null; $select = array($pipes[1]); while (feof($pipes[1]) === false) { if (stream_select($select, $null, $null, null)) { var_dump(stream_get_contents($pipes[1])); } } Expected result: foobar Actual result: -- foo -- Edit this bug report at https://bugs.php.net/bug.php?id=60131&edit=1
[PHP-BUG] Bug #60343 [NEW]: nmake clean results in root dir emptied in some cases
From: cataphract Operating system: Windows PHP version: trunk-SVN-2011-11-20 (SVN) Package: *Compile Issues Bug Type: Bug Bug description:nmake clean results in root dir emptied in some cases Description: When running buildconf and configure on the same source directory, but via different symlinks, the resulting Makefile produces rules that result in nmake clean causing all the files (but not directories) of the source dir being deleted. Actual result: -- The gist https://gist.github.com/1381227 contains two files. In the first, both buildconf and configure were run under C:\Users\Cataphract_\Documents\php-src In the second, buildconf was run under C:\Users\Cataphract\Documents\php-src and configure was run under C:\Users\Cataphract_\Documents\php-src C:\Users\Cataphract_\Documents\php-src and C:\Users\Cataphract\Documents\php-src represent the same directory. nmake clean was run under C:\Users\Cataphract_\Documents\php-src in both cases. -- Edit bug report at https://bugs.php.net/bug.php?id=60343&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60343&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60343&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60343&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60343&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60343&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60343&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60343&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60343&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60343&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60343&r=support Expected behavior: https://bugs.php.net/fix.php?id=60343&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60343&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60343&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60343&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60343&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60343&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60343&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60343&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60343&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60343&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60343&r=mysqlcfg
[PHP-BUG] Bug #60373 [NEW]: Startup errors with log_errors on cause segfault
From: cataphract Operating system: ZTS builds (tested on Win) PHP version: trunk-SVN-2011-11-24 (SVN) Package: Date/time related Bug Type: Bug Bug description:Startup errors with log_errors on cause segfault Description: In ZTS builds, when log_errors is on and there are startup errors, PHP segfaults. Test script: --- Load an inexistent extension in php.ini. Actual result: -- 0:000:x86> kP ChildEBP RetAddr 00a1e310 0f880c3f php5ts_debug!guess_timezone( struct _timelib_tzdb * tzdb = 0x0face790, void *** tsrm_ls = 0x010832a0)+0x2d [c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 841] 00a1e408 0f8810d5 php5ts_debug!get_timezone_info( void *** tsrm_ls = 0x010832a0)+0x4f [c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 868] 00a1e504 0f829d2c php5ts_debug!php_format_date( char * format = 0x0fa759c4 "d-M-Y H:i:s", int format_len = 0n11, long ts = 0n1322156443, int localtime = 0n1, void *** tsrm_ls = 0x010832a0)+0x35 [c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 1118] 00a1e628 0f82f728 php5ts_debug!php_log_err( char * log_message = 0x011e25a0 "PHP Warning: PHP Startup: Unable to load dynamic library 'C:\Users\Cataphract_\Documents\php-src\Debug_TS\php_interbase.dll' - The specified module could not be found... in Unknown on line 0", void *** tsrm_ls = 0x010832a0)+0x11c [c:\users\cataphract_\documents\php-src\main\main.c @ 578] 00a1e7d4 0f694c4d php5ts_debug!php_error_cb( int type = 0n32, char * error_filename = 0x0fa61a90 "Unknown", unsigned int error_lineno = 0, char * format = 0x0fa61a30 "%s", char * args = 0x00a1eaa8 "???")+0x5c8 [c:\users\cataphract_\documents\php-src\main\main.c @ 1005] 00a1ea98 0f82a9a5 php5ts_debug!zend_error( int type = 0n32, char * format = 0x0fa61a30 "%s")+0x24d [c:\users\cataphract_\documents\php-src\zend\zend.c @ 1082] 00a1ec9c 0f82adf2 php5ts_debug!php_verror( char * docref = 0x "", char * params = 0x0fa618f8 "", int type = 0n32, char * format = 0x0fb0e104 "Unable to load dynamic library '%s' - %s", char * args = 0x00a1edac "???", void *** tsrm_ls = 0x010832a0)+0x8c5 [c:\users\cataphract_\documents\php-src\main\main.c @ 801] 00a1ed94 0f9be474 php5ts_debug!php_error_docref0( char * docref = 0x "", void *** tsrm_ls = 0x010832a0, int type = 0n32, char * format = 0x0fb0e104 "Unable to load dynamic library '%s' - %s")+0x42 [c:\users\cataphract_\documents\php-src\main\main.c @ 813] 00a1eef8 0f83dc11 php5ts_debug!php_load_extension( char * filename = 0x011e20f8 "php_interbase.dll", int type = 0n1, int start_now = 0n0, void *** tsrm_ls = 0x010832a0)+0x1d4 [c:\users\cataphract_\documents\php-src\ext\standard\dl.c @ 149] 00a1efdc 0f7fdef6 php5ts_debug!php_load_php_extension_cb( void * arg = 0x00f9c218, void *** tsrm_ls = 0x010832a0)+0x31 [c:\users\cataphract_\documents\php-src\main\php_ini.c @ 351] 00a1f0c4 0f83db87 php5ts_debug!zend_llist_apply( struct _zend_llist * l = 0x0fb6a818, * func = 0x0f83dbe0, void *** tsrm_ls = 0x010832a0)+0x46 [c:\users\cataphract_\documents\php-src\zend\zend_llist.c @ 193] 00a1f1a4 0f82e3b3 php5ts_debug!php_ini_register_extensions( void *** tsrm_ls = 0x010832a0)+0x47 [c:\users\cataphract_\documents\php-src\main\php_ini.c @ 747] 00a1f5f0 0130223e php5ts_debug!php_module_startup( struct _sapi_module_struct * sf = 0x0131f008, struct _zend_module_entry * additional_modules = 0x, unsigned int num_additional_modules = 0)+0xc33 [c:\users\cataphract_\documents\php-src\main\main.c @ 2131] 00a1f6d0 01302938 php!php_cli_startup( struct _sapi_module_struct * sapi_module = 0x0131f008)+0x2e [c:\users\cataphract_\documents\php-src\sapi\cli\php_cli.c @ 414] 00a1f8b8 0131718f php!main( int argc = 0n3, char ** argv = 0x01083140)+0x6b8 [c:\users\cataphract_\documents\php-src\sapi\cli\php_cli.c @ 1336] 00a1f908 01316fbf php!__tmainCRTStartup(void)+0x1bf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe
