Bug #52939 [Csd]: zend_call_function does not respect ZEND_SEND_PREFER_REF
Edit report at http://bugs.php.net/bug.php?id=52939edit=1 ID: 52939 Updated by: dmi...@php.net Reported by:cataphr...@php.net Summary:zend_call_function does not respect ZEND_SEND_PREFER_REF Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Assigned To:dmitry Block user comment: N New Comment: I agree that separation might be omitted, but with your patch we just convert value into reference without separation. In case of no separation we also have to prevent Z_SET_ISREF_PP(fci-params[i]); Previous Comments: [2010-10-14 03:11:26] cataphr...@php.net That does it. On a minor note, the fix does an unnecessary zval separation. The need to separate the zval if !fci-no_separation, the zval is not a reference and the function expects a reference is because, presumably, if the target function expects a reference, it may assume it has one and then change the zval without separation. However, if it *prefers* a reference, it presumably doesn't rely on having one and it's (presumably...) safe not to separate the zval (see http://bugs.php.net/patch-display.php?bug=52939patch=zend_call_user_function_prefer_refrevision=1285639039 ) [2010-10-13 10:52:13] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-10-13 10:51:41] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304364 Log: Fixed bug #52939 (zend_call_function does not respect ZEND_SEND_PREFER_REF) [2010-10-12 23:49:25] cataphr...@php.net This last test is exactly the same thing, and still gives an error. The only thing that would be different would be call_user_func_array(array_multisort, array(array(row1 = 2, row2 = 1))); because now the inner array refcount would be 1 and in that case zend_call_function flips is_ref. This code $args = array(array(row1 = 2, row2 = 1)); call_user_func_array(array_multisort, $args); should still pass $args[0] by value. The fact that it can't be modified is irrelevant; array_multisort explicitly declares it can accept a value (probably because it can accept multiple arrays and one may want to modify only some). [2010-10-12 20:48:50] dmi...@php.net Note that array($ar1) creates an array with a copy of $ar1 and its modification doesn't affect the original $ar1 value. Probably the proper test would be ?php $args = array(array(row1 = 2, row2 = 1)); call_user_func_array(array_multisort, $args); var_dump($args[0]); ? I'll check if it works tomorrow. But anyway it's not the thing you like. 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=52939 -- Edit this bug report at http://bugs.php.net/bug.php?id=52939edit=1
Req #53052 [Com]: PHP_INI_SYSTEM level of allow_url_fopen prevents disabling it
Edit report at http://bugs.php.net/bug.php?id=53052edit=1
ID: 53052
Comment by: php dot net at site dot lanzz dot org
Reported by:php dot net at site dot lanzz dot org
Summary:PHP_INI_SYSTEM level of allow_url_fopen prevents
disabling it
Status: Open
Type: Feature/Change Request
Package:*Configuration Issues
Operating System: Irrelevant
PHP Version:5.2.14
Block user comment: N
New Comment:
The url wrappers are an unfortunate feature that should have never been
implemented the way it is. Still, there is existing code out there that
relies
on it, so neither reimplementing it better nor disabling it globally via
allow_url_fopen seem like good options.
Why not rely on the php_admin_flag mechanism for restricting
allow_url_fopen? It
will make it possible for administrators to disable it globally without
letting
end-users to re-enable it (for example in a shared hosting context), or
let
administrators leave it unrestricted and manage it at runtime (for
example in a
dedicated server).
I find it useful to be able to turn on url fopen in a controlled manner,
like
so:
ini_set('allow_url_fopen', 1);
$content = file_get_contents('http://remote/resource');
ini_set('allow_url_fopen', 0);
This approach will not be possible if only tightening is allowed, as
this code
will run correctly only once per script execution. Using php_admin_flag
this
code either will work as expected (turning allow_url_fopen on and off
and
accessing the resource), or will not work at all, which will be much
easier to
catch in development.
Previous Comments:
[2010-10-14 03:22:14] cataphr...@php.net
We could presumably change it to PHP_INI_ALL and allow it only to be
tightened, like open_basedir. It's certainly something to be
considered.
Still, allow_url_fopen is not that dangerous. Sure it could make the
effects of some vulnerabilities worse (like if you pass unvalidated data
to to copy()...), but it's not that easy to use it dangerously.
[2010-10-13 14:10:39] php dot net at site dot lanzz dot org
Description:
The documentation states that [allow_url_fopen] can only be set in
php.ini due
to security reasons. This is a completely wrong approach, as it also
prevents
security-conscious developers to DISABLE the dangerous allow_url_fopen
option,
if it is enabled server-wide (for example in a shared hosting setup).
Having a single point of control over allow_url_fopen forces the entire
webserver and all websites and applications to share the same setting,
which in
some cases would force administrators to enable the option due to poorly
written
third-party code which might be unfeasible to fix or replace, which
would lower
security for other code that relies on allow_url_fopen being off, and
it's not
possible to selectively disable it where it really is not needed.
The added security of restricting allow_url_fopen to php.ini only is
questionable, as malicious users can use other means to access remote
URLs,
while legitimate users are left without the option of controlled access
to
remote URLs.
The best scenario would be a globally disabled allow_url_fopen option
(which
really should be the default), with the possibility for controlled
enabling of
the feature only where its needed.
Test script:
---
# php.ini
allow_url_fopen = On
# test.php
ini_set('allow_url_fopen', 0);
print(ini_get('allow_url_fopen')? 'enabled', 'disabled');
Expected result:
disabled
Actual result:
--
enabled
--
Edit this bug report at http://bugs.php.net/bug.php?id=53052edit=1
Bug #52939 [Csd]: zend_call_function does not respect ZEND_SEND_PREFER_REF
Edit report at http://bugs.php.net/bug.php?id=52939edit=1 ID: 52939 Updated by: cataphr...@php.net Reported by:cataphr...@php.net Summary:zend_call_function does not respect ZEND_SEND_PREFER_REF Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Assigned To:dmitry Block user comment: N New Comment: Ah right, the part after the if in line #854 is still executed. You also seem to have missed an implication of in your commit, because with a value + SEND_PREFER_REF, the newly separated value will be have is_ref set to 1 by that part in #880 - #882. The test script in the report gives this result: direct call [0x43436c0, refcount=1] int(1) [0x4343d20, refcount=2] string(1) a [0x4343710, refcount=1] int(7) call via zend_call_function [0x43436c0, refcount=3] int(1) [0x4343d20, refcount=4] string(1) a [0x43426d8, refcount=2] int(7) Previous Comments: [2010-10-14 08:11:34] dmi...@php.net I agree that separation might be omitted, but with your patch we just convert value into reference without separation. In case of no separation we also have to prevent Z_SET_ISREF_PP(fci-params[i]); [2010-10-14 03:11:26] cataphr...@php.net That does it. On a minor note, the fix does an unnecessary zval separation. The need to separate the zval if !fci-no_separation, the zval is not a reference and the function expects a reference is because, presumably, if the target function expects a reference, it may assume it has one and then change the zval without separation. However, if it *prefers* a reference, it presumably doesn't rely on having one and it's (presumably...) safe not to separate the zval (see http://bugs.php.net/patch-display.php?bug=52939patch=zend_call_user_function_prefer_refrevision=1285639039 ) [2010-10-13 10:52:13] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-10-13 10:51:41] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304364 Log: Fixed bug #52939 (zend_call_function does not respect ZEND_SEND_PREFER_REF) [2010-10-12 23:49:25] cataphr...@php.net This last test is exactly the same thing, and still gives an error. The only thing that would be different would be call_user_func_array(array_multisort, array(array(row1 = 2, row2 = 1))); because now the inner array refcount would be 1 and in that case zend_call_function flips is_ref. This code $args = array(array(row1 = 2, row2 = 1)); call_user_func_array(array_multisort, $args); should still pass $args[0] by value. The fact that it can't be modified is irrelevant; array_multisort explicitly declares it can accept a value (probably because it can accept multiple arrays and one may want to modify only some). 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=52939 -- Edit this bug report at http://bugs.php.net/bug.php?id=52939edit=1
[PHP-BUG] Bug #53063 [NEW]: xsl:include and xsl:import are broken
From:
Operating system: Ubuntu 10.04
PHP version: 5.3.3
Package: XSLT related
Bug Type: Bug
Bug description:xsl:include and xsl:import are broken
Description:
Somewhere between 5.3.0 and 5.3.2, the security model for XSL has been over
tightened. XSL stylesheets which refer to other stylesheet by xsl:import
or xsl:include now fail to work.
Test script:
---
?php
// PHP 5.3.2 XSLT BUG - xsl:import (and xsl:include) are broken
$aDOM= new DOMDocument();
$aDOM-loadXML('?xml version=1.0?etc/');
$stylesheet= new DOMDocument();
$proc= new XSLTProcessor();
$stylesheet-loadXML('?xml version=1.0?stylesheet version=1.0
xmlns=http://www.w3.org/1999/XSL/Transform;import
href=somesheet.xslt/template match=///stylesheet');
$proc-importStyleSheet($stylesheet);
$oops= $proc-transformToDoc($aDOM);
?
Expected result:
Assuming there is a valid stylesheet at somesheet.xslt, the transform
should work as per the W3C spec.
Am I missing something? Is there, for example, a way to set this security
default somewhere? Or a class method for XSLTProcessor to disable this?
Actual result:
--
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: error in
/home/robin/f2f/hardcode/xsl-import.php on line 10
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: Local file read for
/home/robin/f2f/hardcode/somesheet.xslt refused in
/home/robin/f2f/hardcode/xsl-import.php on line 10
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: error in
/home/robin/f2f/hardcode/xsl-import.php on line 10
Warning: XSLTProcessor::importStylesheet()
[xsltprocessor.importstylesheet]: xsl:import: read rights for
/home/robin/f2f/hardcode/somesheet.xslt denied in
/home/robin/f2f/hardcode/xsl-import.php on line 10
Warning: XSLTProcessor::transformToDoc() [xsltprocessor.transformtodoc]: No
stylesheet associated to this object in
/home/robin/f2f/hardcode/xsl-import.php on line 11
--
Edit bug report at http://bugs.php.net/bug.php?id=53063edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53063r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53063r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53063r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53063r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53063r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53063r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53063r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53063r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53063r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53063r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53063r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53063r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53063r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53063r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53063r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53063r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53063r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53063r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53063r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53063r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53063r=mysqlcfg
[PHP-BUG] Bug #53064 [NEW]: filsize return 0 after is_file
From: Operating system: Linux Ubuntu PHP version: 5.2.14 Package: Filesystem function related Bug Type: Bug Bug description:filsize return 0 after is_file Description: When using is_file() on a file which is open via fopen(), the filesize() function returns 0, even after fclose() is called; see test script. Test script: --- $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); var_dump($isFile, file_get_contents($filename), filesize($filename)); Expected result: boolean true string 'some data goes here!' (length=20) int 20 Actual result: -- boolean true string 'some data goes here!' (length=20) int 0 -- Edit bug report at http://bugs.php.net/bug.php?id=53064edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53064r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53064r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53064r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53064r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53064r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53064r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53064r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53064r=needscript Try newer version: http://bugs.php.net/fix.php?id=53064r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53064r=support Expected behavior: http://bugs.php.net/fix.php?id=53064r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53064r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53064r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53064r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53064r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53064r=dst IIS Stability: http://bugs.php.net/fix.php?id=53064r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53064r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53064r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53064r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53064r=mysqlcfg
Bug #52939 [Csd]: zend_call_function does not respect ZEND_SEND_PREFER_REF
Edit report at http://bugs.php.net/bug.php?id=52939edit=1 ID: 52939 Updated by: dmi...@php.net Reported by:cataphr...@php.net Summary:zend_call_function does not respect ZEND_SEND_PREFER_REF Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:trunk-SVN-2010-09-28 (SVN) Assigned To:dmitry Block user comment: N New Comment: right, but it can't break something because the function can accept references. It's just unnecessary copying, but I suppose that it's a very rare case. Previous Comments: [2010-10-14 08:28:31] cataphr...@php.net Ah right, the part after the if in line #854 is still executed. You also seem to have missed an implication of in your commit, because with a value + SEND_PREFER_REF, the newly separated value will be have is_ref set to 1 by that part in #880 - #882. The test script in the report gives this result: direct call [0x43436c0, refcount=1] int(1) [0x4343d20, refcount=2] string(1) a [0x4343710, refcount=1] int(7) call via zend_call_function [0x43436c0, refcount=3] int(1) [0x4343d20, refcount=4] string(1) a [0x43426d8, refcount=2] int(7) [2010-10-14 08:11:34] dmi...@php.net I agree that separation might be omitted, but with your patch we just convert value into reference without separation. In case of no separation we also have to prevent Z_SET_ISREF_PP(fci-params[i]); [2010-10-14 03:11:26] cataphr...@php.net That does it. On a minor note, the fix does an unnecessary zval separation. The need to separate the zval if !fci-no_separation, the zval is not a reference and the function expects a reference is because, presumably, if the target function expects a reference, it may assume it has one and then change the zval without separation. However, if it *prefers* a reference, it presumably doesn't rely on having one and it's (presumably...) safe not to separate the zval (see http://bugs.php.net/patch-display.php?bug=52939patch=zend_call_user_function_prefer_refrevision=1285639039 ) [2010-10-13 10:52:13] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-10-13 10:51:41] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304364 Log: Fixed bug #52939 (zend_call_function does not respect ZEND_SEND_PREFER_REF) 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=52939 -- Edit this bug report at http://bugs.php.net/bug.php?id=52939edit=1
[PHP-BUG] Req #53065 [NEW]: Allow spl_autoload to be case sensitive on *nix
From:
Operating system: Ubuntu Linux 10.04
PHP version: 5.3.3
Package: SPL related
Bug Type: Feature/Change Request
Bug description:Allow spl_autoload to be case sensitive on *nix
Description:
I Opened This because #48129 is set to won't fix. But this affects major
frameworks i.e. (ZendFramework, FLOW3).It would be nice to tell
spl_autoload() not to lowercase all filenames so that these framworks can
benefit from its performance.
To stay backwards compatible this could be done via php.ini or a function
call.
I would suggest spl_autoload_casesensitive in php.ini or a method
spl_autoload_casesensitive(bool $flag);
Another more compatible option could be handling this inside of
spl_autoload().
Check for unmodified case first (i.e. Zend/Db/Adapter/Abstract.php) and if
this is not available try lowercased (i.e. zend/db/adapter/abstract.php)
This Solutions won't break BC!
Test script:
---
?php
namespace Test;
use Zend\Controller;
slp_autoload_casesensitive(true);
spl_autoload_extensions('.php');
spl_autoload_register();
// this should load from correct ZF path: Zend/Controller/Front.php;
$request = new Controller\Front();
Expected result:
Class should be loaded from Zend/Controller/Front.php in include path
Actual result:
--
Class is always loaded from zend/controller/front.php in include path
--
Edit bug report at http://bugs.php.net/bug.php?id=53065edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53065r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53065r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53065r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53065r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53065r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53065r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53065r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53065r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53065r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53065r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53065r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53065r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53065r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53065r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53065r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53065r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53065r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53065r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53065r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53065r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53065r=mysqlcfg
[PHP-BUG] Bug #53067 [NEW]: DateTime::add DateTime::sub changes original dateTime object
From:
Operating system: Windows
PHP version: 5.3.3
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::add DateTime::sub changes original dateTime object
Description:
Documentation says it should return new Object thought it returns modified
old.
PHP 5.3.2 (cli) (built: Mar 3 2010 20:36:54)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
$day_interval = new DateInterval('P1D');
$cur_date = new DateTime('2000-01-02');
echo $cur_date-add($day_interval)-format('Y-m-d');
echo $cur_date-sub($day_interval)-format('Y-m-d');
Expected result:
2000-01-03
2000-01-01
Actual result:
--
2000-01-03
2000-01-02
--
Edit bug report at http://bugs.php.net/bug.php?id=53067edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53067r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53067r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53067r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53067r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53067r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53067r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53067r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53067r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53067r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53067r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53067r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53067r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53067r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53067r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53067r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53067r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53067r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53067r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53067r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53067r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53067r=mysqlcfg
Bug #53067 [Opn]: DateTime::add DateTime::sub changes original dateTime object
Edit report at http://bugs.php.net/bug.php?id=53067edit=1
ID: 53067
User updated by:bogunov at gmail dot com
Reported by:bogunov at gmail dot com
Summary:DateTime::add DateTime::sub changes original
dateTime object
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows
-PHP Version:5.3.3
+PHP Version:5.3.2
Block user comment: N
New Comment:
5.3.2 version instead of 5.3.3 as selected first time
Previous Comments:
[2010-10-14 15:31:39] bogunov at gmail dot com
Description:
Documentation says it should return new Object thought it returns
modified old.
PHP 5.3.2 (cli) (built: Mar 3 2010 20:36:54)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Test script:
---
$day_interval = new DateInterval('P1D');
$cur_date = new DateTime('2000-01-02');
echo $cur_date-add($day_interval)-format('Y-m-d');
echo $cur_date-sub($day_interval)-format('Y-m-d');
Expected result:
2000-01-03
2000-01-01
Actual result:
--
2000-01-03
2000-01-02
--
Edit this bug report at http://bugs.php.net/bug.php?id=53067edit=1
[PHP-BUG] Bug #53068 [NEW]: Soap header object without attributes
From:
Operating system: Ubuntu
PHP version: 5.3.3
Package: SOAP related
Bug Type: Bug
Bug description:Soap header object without attributes
Description:
when soap server handles the soap header, the object version of the header
does not contain it's attributes.
Test script:
---
server
?php
class testSoap{
protected $auth;
public function login($data){
$this-auth=print_r($data,1);
}
public function getLogin(){
return $this-auth;
}
}
$server = new SoapServer('test.wsdl',
array('cache_wsdl'=WSDL_CACHE_NONE));
$server-setObject(new testSoap());
$server-handle();
?
client
?php
$cl = new SoapClient('http://sviluppo.netanday.it/wsdltest/test.wsdl',
array('cache_wsdl'=WSDL_CACHE_NONE, 'trace'=true)
);
$xml = gs:login xmlns:gs=\http://www.goetas.com\;logdata name='user'
password='pwd' //gs:login;
$cl-__setSoapHeaders(array(new SoapHeader('http://www.goetas.com',
'login', new \SoapVar($xml, XSD_ANYXML;
echo $cl-getLogin();
?
Expected result:
stdClass Object
(
[logdata] = stdClass Object
(
[name] = user
[password] = pwd
)
)
Actual result:
--
stdClass Object
(
[logdata] =
)
--
Edit bug report at http://bugs.php.net/bug.php?id=53068edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53068r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53068r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53068r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53068r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53068r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53068r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53068r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53068r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53068r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53068r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53068r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53068r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53068r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53068r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53068r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53068r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53068r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53068r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53068r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53068r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53068r=mysqlcfg
Bug #53064 [Opn]: filsize return 0 after is_file
Edit report at http://bugs.php.net/bug.php?id=53064edit=1 ID: 53064 Updated by: cataphr...@php.net Reported by:mraaijmakers at gmail dot com Summary:filsize return 0 after is_file Status: Open Type: Bug Package:Filesystem function related Operating System: Linux Ubuntu PHP Version:5.2.14 Block user comment: N New Comment: read: negligible Previous Comments: [2010-10-14 18:11:29] cataphr...@php.net That's just stale stat cache. This will work: ?php $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); clearstatcache(false, $filename); var_dump($isFile, file_get_contents($filename), filesize($filename)); I'm not closing because maybe there's a way to invalidate the cache for that file with a negligent performance penalty. [2010-10-14 08:38:22] mraaijmakers at gmail dot com Description: When using is_file() on a file which is open via fopen(), the filesize() function returns 0, even after fclose() is called; see test script. Test script: --- $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); var_dump($isFile, file_get_contents($filename), filesize($filename)); Expected result: boolean true string 'some data goes here!' (length=20) int 20 Actual result: -- boolean true string 'some data goes here!' (length=20) int 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53064edit=1
Bug #53005 [Com]: iconv() fails in ext/iconv/iconv.c php_iconv_string
Edit report at http://bugs.php.net/bug.php?id=53005edit=1 ID: 53005 Comment by: reggaedancer at ymail dot com Reported by:php at jdrtech dot com Summary:iconv() fails in ext/iconv/iconv.c php_iconv_string Status: Closed Type: Bug Package:Unknown/Other Function Operating System: Solaris 10 Sparc PHP Version:5.3.3 Block user comment: N New Comment: Ubelievable!! It really works. I just added: LD_PRELOAD_32=/usr/local/lib/preloadable_libiconv.so export LD_PRELOAD_32 and the Apache/PHP with iconv is working and not crashing anymore. I tried to use disable_functions in PHP to avoid iconv, but this preload solution is great. Thank you very much for your help. Previous Comments: [2010-10-13 15:12:45] wes at jdrtech dot com libiconv should provide the preloadable library preloadable_libiconv.so. I edited apachectl: -- case $ARG in start) LD_PRELOAD_64=/fcgi/lib/preloadable_libiconv.so export LD_PRELOAD_64 if [ $RUNNING -eq 1 ]; then echo $0 $ARG: httpd (pid $PID) already running continue fi of course your library location may differ, probably /usr/local/lib and LD_PRELOAD_32 if your using 32 bit good luck [2010-10-13 12:26:20] reggaedancer at ymail dot com Hello, I have the same issue on Solaris 10 x86, PHP 5.3.3 after running iconv PHP script, PHP crashed and created a core dump. What do you mean by needed to preload. How can I fix this issue ? [2010-10-07 01:45:16] php at jdrtech dot com needed to do preload, runs great [2010-10-06 22:58:19] php at jdrtech dot com Description: PHP runs great with the exception of iconv. I've created a test program that uses libiconv.so.2.5.0 with expected results CLI command: ./php ./test.php Original : This is the Euro symbol '?'. TRANSLIT : Segmentation Fault (core dumped) CC: Sun C++ 5.8 2005/10/13 cc: Sun C 5.8 2005/10/13 Configure: export CC=cc CFLAGS=-xarch=v9a CXXFLAGS=-xarch=v9a CPPFLAGS=-I/fcgi/include LDFLAGS=-L/fcgi/lib ./configure --prefix=/fcgi --with-mysql=/opt/mysql/mysql --enable-mbstring --with-apache=../apache_1.3.41 -with-dom --with-xsl=/fcgi --with-iconv-dir=/fcgi --enable-debug ldd php libexslt.so.0 = /fcgi/lib/libexslt.so.0 libpthread.so.1 = /lib/64/libpthread.so.1 libsocket.so.1 =/lib/64/libsocket.so.1 libnsl.so.1 = /lib/64/libnsl.so.1 libm.so.2 = /lib/64/libm.so.2 librt.so.1 =/lib/64/librt.so.1 libmysqlclient.so.16 = /usr/local/mysql/lib/libmysqlclient.so.16 libthread.so.1 =/lib/64/libthread.so.1 libxslt.so.1 = /fcgi/lib/libxslt.so.1 libxml2.so.2 = /fcgi/lib/libxml2.so.2 libresolv.so.2 =/lib/64/libresolv.so.2 libgen.so.1 = /lib/64/libgen.so.1 libiconv.so.2 = /fcgi/lib/libiconv.so.2 libc.so.1 = /lib/64/libc.so.1 libz.so.1 = /usr/lib/64/libz.so.1 libmp.so.2 =/lib/64/libmp.so.2 libmd5.so.1 = /lib/64/libmd5.so.1 libscf.so.1 = /lib/64/libscf.so.1 libaio.so.1 = /lib/64/libaio.so.1 libdoor.so.1 = /lib/64/libdoor.so.1 libuutil.so.1 = /lib/64/libuutil.so.1 /platform/SUNW,Sun-Blade-100/lib/sparcv9/libc_psr.so.1 /platform/SUNW,Sun-Blade-100/lib/sparcv9/libmd5_psr.so.1 Test script: --- ?php $text = This is the Euro symbol '?'.; echo 'Original : ', $text, PHP_EOL; echo 'TRANSLIT : ', iconv(UTF-8, ISO-8859-1//TRANSLIT, $text), PHP_EOL; echo 'IGNORE : ', iconv(UTF-8, ISO-8859-1//IGNORE, $text), PHP_EOL; echo 'Plain: ', iconv(UTF-8, ISO-8859-1, $text), PHP_EOL; ? Expected result: unknown Actual result: -- t...@1 (l...@1) program terminated by signal SEGV (no mapping at the fault address) 0x7d35a544: _iconv+0x002c: jmp %l5 Current function is php_iconv_string 501 result = iconv(cd, (char **) in_p, in_left, (char **) out_p, out_left); -- Edit this bug report at http://bugs.php.net/bug.php?id=53005edit=1
Bug #53064 [Opn]: filsize return 0 after is_file
Edit report at http://bugs.php.net/bug.php?id=53064edit=1 ID: 53064 Updated by: cataphr...@php.net Reported by:mraaijmakers at gmail dot com Summary:filsize return 0 after is_file Status: Open Type: Bug Package:Filesystem function related Operating System: Linux Ubuntu PHP Version:5.2.14 Block user comment: N New Comment: That's just stale stat cache. This will work: ?php $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); clearstatcache(false, $filename); var_dump($isFile, file_get_contents($filename), filesize($filename)); I'm not closing because maybe there's a way to invalidate the cache for that file with a negligent performance penalty. Previous Comments: [2010-10-14 08:38:22] mraaijmakers at gmail dot com Description: When using is_file() on a file which is open via fopen(), the filesize() function returns 0, even after fclose() is called; see test script. Test script: --- $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); var_dump($isFile, file_get_contents($filename), filesize($filename)); Expected result: boolean true string 'some data goes here!' (length=20) int 20 Actual result: -- boolean true string 'some data goes here!' (length=20) int 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53064edit=1
Bug #48614 [Com]: Loading pdo_sqlite.so fails: undefined symbol: sqlite3_libversion
Edit report at http://bugs.php.net/bug.php?id=48614edit=1 ID: 48614 Comment by: jd at cpanel dot net Reported by:kaspernj at gmail dot com Summary:Loading pdo_sqlite.so fails: undefined symbol: sqlite3_libversion Status: Assigned Type: Bug Package:PDO related Operating System: Ubuntu Jaunty PHP Version:5.3.0RC4 Assigned To:scottmac Block user comment: N New Comment: The problem is that pdo_sqlite compiles against the embedded copy of sqlite3 but doesn't include the sqlite3 object files in the final pdo_sqlite.so. Ugly patch directly against the configure script: --- php-5.3.3.orig/configure2010-07-21 05:53:06.0 -0500 +++ php-5.3.3/configure 2010-10-14 09:40:17.0 -0500 @@ -75183,6 +75183,12 @@ else # use bundled libs + + # This change is anchored here to avoid patch being misapplied. This really only needs to be added + # when pdo_sqlite is compiled shared and using the bundled sqlite3. It shouldn't hurt so long as the + # bundled sqlite3 is used though. + shared_objects_pdo_sqlite=$shared_objects_pdo_sqlite ext/sqlite3/libsqlite/sqlite3.lo + if test $enable_maintainer_zts = yes; then threadsafe_flags=-DSQLITE_THREADSAFE=1 else Previous Comments: [2010-06-08 12:52:20] kontakt at beberlei dot de You can get this working with the following configure: --without-sqlite --with-sqlite3=shared --with-pdo-sqlite=shared,/usr More information in this thread: http://news.php.net/php.pdo/427 [2010-05-25 23:50:30] ashoat at gmail dot com The problem is still occurring. There really ought to be a patch by now. [2010-04-25 13:00:18] ovidio dot balan at gmail dot com lol .. :( [2010-04-05 15:41:51] koubel at volny dot cz Year will be gone, and problem is still here: tested on 5.3.2 debian stable [2010-02-23 03:54:27] l27n at yahoo dot com Same problem, PHP 5.3.1, CENTOS 5.4 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=48614 -- Edit this bug report at http://bugs.php.net/bug.php?id=48614edit=1
Bug #48607 [Com]: fwrite() doesn't check reply from ftp server before exiting
Edit report at http://bugs.php.net/bug.php?id=48607edit=1
ID: 48607
Comment by: eric dot caron at gmail dot com
Reported by:karachi at mail dot ru
Summary:fwrite() doesn't check reply from ftp server before
exiting
Status: Verified
Type: Bug
Package:Streams related
Operating System: FreeBSD
PHP Version:5.2.10
Block user comment: N
New Comment:
I can reproduce this on my CentOS 5 box running PHP 5.3.3. It occurs
when sending a large file across a slow network. Wireshark reports
getting the QUIT before the FTP server sends TRANSFER COMPLETE. Adding
the sleep before the close fixes the issue.
Reproduce code:
--
?php
$fileName = SOME_LARGE_BINARY_FILE;
$conn_id = ftp_connect(FTP_SERVER);
$login_result = ftp_login($conn_id, USERNAME, PASSWORD);
ftp_pasv($conn_id, true);
ftp_put($conn_id, 'file_dump', $fileName, FTP_BINARY);
//Putting a sleep here fixes the problem
ftp_close($conn_id);
Previous Comments:
[2010-08-31 19:03:59] savageman86 at yahoo dot fr
I also ran into this bug. One possible solution is to use a custom ftp
stream wrapper which encapsulates the ftp_* functions, because
ftp_fput() works well and waits the file has finished uploading before
returning.
At the end, the only current solution is to use the ftp lib and not the
default ftp stream wrapper, which is buggy. It's sad, because stream
wrappers are really a killer feature ! :-)
[2009-12-17 21:59:06] b dot vontobel at meteonews dot ch
Sorry, just realized that I went a little bit too far when cleaning up
my mess for the diff/patch. :)
--- php-5.3.1/ext/standard/ftp_fopen_wrapper.c 2008-12-31
11:15:49.0 +
+++ php-5.3.1-ftp_fopen_wrapper_patch/ext/standard/ftp_fopen_wrapper.c
2009-12-17 21:32:53.0 +
@@ -97,14 +97,34 @@
*/
static int php_stream_ftp_stream_close(php_stream_wrapper *wrapper,
php_stream *stream TSRMLS_DC)
{
+ int ret = 0, result = 0;
+ char tmp_line[512];
php_stream *controlstream = (php_stream *)stream-wrapperdata;
-
+
+ /* For write modes close data stream first to signal EOF to
server */
+ if (strpbrk(stream-mode, wa+)) {
+ if (stream controlstream) {
+ php_stream_close(stream);
+ stream = NULL;
+
+ result = GET_FTP_RESULT(controlstream);
+ if (result != 226 result != 250) {
+ php_error_docref(NULL TSRMLS_CC,
E_WARNING, FTP server reports %s, tmp_line);
+ ret = EOF;
+ }
+ } else {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
Broken streams to FTP server);
+ ret = EOF;
+ }
+ }
+
if (controlstream) {
php_stream_write_string(controlstream, QUIT\r\n);
php_stream_close(controlstream);
- stream-wrapperdata = NULL;
+ if (stream)
+ stream-wrapperdata = NULL;
}
- return 0;
+ return ret;
}
Also make sure that I or somebody else afterwards really does not call
something on/in the streams after closing and probably freeing them
(didn't really check out the internals of _php_stream_free() et al. --
and the control stream sort of being embedded within the data stream
here, but me having to close them the other way round due to the FTP
protocol, didn't really help in understanding what might go wrong
somewhere deep in your API). But as I said, for me the patch works.
[2009-12-17 20:17:41] b dot vontobel at meteonews dot ch
Just stumbled across this (still in 5.3.1) a few days ago, trying to
transmit data to three different FTP servers. One of the servers
_never_ got a file, one got files, but in 9 out of 10 runs the last
part of the files was cut off, only the last one got the files intact
in about 8 of 10 runs (with the others also corrupted).
I didn't find this bug report at first and so I opened up the PHP
source for the first time in my life and was rather shocked: There's
really no way that write operations using the ftp stream wrapper ever
could've worked. If it works, it's out of pure luck. Was this never
tested?
The problem is, that FTP (see RFC959) uses the tear down of the
_data_stream_ as its EOF marker. What this code does on the other
hand, is just send a QUIT on the control stream and then tear down
that one. So from the perspective of the FTP server it looks like an
abort (transmission still in progress, but control
[PHP-BUG] Bug #53070 [NEW]: Calling enchant_broker_get_dict_path before set_path crashes php
From: Operating system: Windows 7 Home Premium PHP version: 5.3.3 Package: *Spelling functions Bug Type: Bug Bug description:Calling enchant_broker_get_dict_path before set_path crashes php Description: Whenever I try to call (the undocumented function) enchant_broker_get_dict_path before enchant_broker_set_dict_path my PHP instance crashes. My php.ini contains the following entries: enchant support enabled Version 1.1.0 Libenchant Version 1.5.0 or later Revision$Revision: 298870 $ ispellIspell Provider C:\PHP\libenchant_ispell.dll myspell Myspell Provider C:\PHP\libenchant_myspell.dll Test script: --- ?php $broker = enchant_broker_init(); enchant_broker_get_dict_path($broker, ENCHANT_ISPELL); ? Expected result: Either false because no dictionary path is set yet or an empty string or some kind. Actual result: -- Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 892 Process Image C:\PHP\php.exe System Up-Time 03:30:23 Process Up-Time 00:00:31 Thread 0 - System ID 5160 Entry point php+2dda Create time 14-10-2010 22:39:46 Time spent in user mode 0 Days 0:0:0.717 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source php_enchant!get_module+6f0 0002 027ce2b0 php5!execute+cdf 02800080 027cdc80 02800080 php5!execute+4c25 00c0ebe8 00c0fe9c 00c0fc84 php5!execute+1f0 PHP_ENCHANT!GET_MODULE+6F0WARNING - DebugDiag was not able to locate debug symbols for php_enchant.dll, so the information below may be incomplete. In php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!get_module+6f0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name: C:\PHP\ext\php_enchant.dll Symbol Type: Export Base address: 0x003d Time Stamp: Wed Jul 21 21:35:15 2010 Checksum: 0x00012284 Comments: Thanks to Pierre-Alain Joye, Ilia Alshanetsky COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: enchant ISAPIFilter: False File Version: 5.3.3 Managed DLL: False Internal Name: ENCHANT extension VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php_enchant.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_enchant.dll Module name: php_enchant Private Build: Single Threaded: False Product Name: PHP Module Size: 32,00 KBytes Product Version: 5.3.3 Symbol File Name: php_enchant.dll Special Build: -- Edit bug report at http://bugs.php.net/bug.php?id=53070edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53070r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53070r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53070r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53070r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53070r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53070r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53070r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53070r=needscript Try newer version: http://bugs.php.net/fix.php?id=53070r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53070r=support Expected behavior: http://bugs.php.net/fix.php?id=53070r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53070r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53070r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53070r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53070r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53070r=dst IIS Stability: http://bugs.php.net/fix.php?id=53070r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53070r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53070r=float No Zend Extensions:
Bug #53070 [Opn]: Calling enchant_broker_get_dict_path before set_path crashes php
Edit report at http://bugs.php.net/bug.php?id=53070edit=1 ID: 53070 Updated by: fel...@php.net Reported by:iwanluijks at gmail dot com Summary:Calling enchant_broker_get_dict_path before set_path crashes php Status: Open Type: Bug Package:*Spelling functions Operating System: Windows 7 Home Premium PHP Version:5.3.3 Block user comment: N New Comment: I can't reproduce it on linux. Previous Comments: [2010-10-14 22:53:13] iwanluijks at gmail dot com Description: Whenever I try to call (the undocumented function) enchant_broker_get_dict_path before enchant_broker_set_dict_path my PHP instance crashes. My php.ini contains the following entries: enchant support enabled Version 1.1.0 Libenchant Version 1.5.0 or later Revision$Revision: 298870 $ ispellIspell Provider C:\PHP\libenchant_ispell.dll myspell Myspell Provider C:\PHP\libenchant_myspell.dll Test script: --- ?php $broker = enchant_broker_init(); enchant_broker_get_dict_path($broker, ENCHANT_ISPELL); ? Expected result: Either false because no dictionary path is set yet or an empty string or some kind. Actual result: -- Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 892 Process Image C:\PHP\php.exe System Up-Time 03:30:23 Process Up-Time 00:00:31 Thread 0 - System ID 5160 Entry point php+2dda Create time 14-10-2010 22:39:46 Time spent in user mode 0 Days 0:0:0.717 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source php_enchant!get_module+6f0 0002 027ce2b0 php5!execute+cdf 02800080 027cdc80 02800080 php5!execute+4c25 00c0ebe8 00c0fe9c 00c0fc84 php5!execute+1f0 PHP_ENCHANT!GET_MODULE+6F0WARNING - DebugDiag was not able to locate debug symbols for php_enchant.dll, so the information below may be incomplete. In php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!get_module+6f0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name: C:\PHP\ext\php_enchant.dll Symbol Type: Export Base address: 0x003d Time Stamp: Wed Jul 21 21:35:15 2010 Checksum: 0x00012284 Comments: Thanks to Pierre-Alain Joye, Ilia Alshanetsky COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: enchant ISAPIFilter: False File Version: 5.3.3 Managed DLL: False Internal Name: ENCHANT extension VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php_enchant.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_enchant.dll Module name: php_enchant Private Build: Single Threaded: False Product Name: PHP Module Size: 32,00 KBytes Product Version: 5.3.3 Symbol File Name: php_enchant.dll Special Build: -- Edit this bug report at http://bugs.php.net/bug.php?id=53070edit=1
Bug #53070 [Opn-Fbk]: Calling enchant_broker_get_dict_path before set_path crashes php
Edit report at http://bugs.php.net/bug.php?id=53070edit=1 ID: 53070 Updated by: paj...@php.net Reported by:iwanluijks at gmail dot com Summary:Calling enchant_broker_get_dict_path before set_path crashes php -Status: Open +Status: Feedback Type: Bug Package:*Spelling functions Operating System: Windows 7 Home Premium PHP Version:5.3.3 Block user comment: N New Comment: Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. Previous Comments: [2010-10-14 23:15:30] fel...@php.net I can't reproduce it on linux. [2010-10-14 22:53:13] iwanluijks at gmail dot com Description: Whenever I try to call (the undocumented function) enchant_broker_get_dict_path before enchant_broker_set_dict_path my PHP instance crashes. My php.ini contains the following entries: enchant support enabled Version 1.1.0 Libenchant Version 1.5.0 or later Revision$Revision: 298870 $ ispellIspell Provider C:\PHP\libenchant_ispell.dll myspell Myspell Provider C:\PHP\libenchant_myspell.dll Test script: --- ?php $broker = enchant_broker_init(); enchant_broker_get_dict_path($broker, ENCHANT_ISPELL); ? Expected result: Either false because no dictionary path is set yet or an empty string or some kind. Actual result: -- Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 892 Process Image C:\PHP\php.exe System Up-Time 03:30:23 Process Up-Time 00:00:31 Thread 0 - System ID 5160 Entry point php+2dda Create time 14-10-2010 22:39:46 Time spent in user mode 0 Days 0:0:0.717 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source php_enchant!get_module+6f0 0002 027ce2b0 php5!execute+cdf 02800080 027cdc80 02800080 php5!execute+4c25 00c0ebe8 00c0fe9c 00c0fc84 php5!execute+1f0 PHP_ENCHANT!GET_MODULE+6F0WARNING - DebugDiag was not able to locate debug symbols for php_enchant.dll, so the information below may be incomplete. In php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!get_module+6f0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name: C:\PHP\ext\php_enchant.dll Symbol Type: Export Base address: 0x003d Time Stamp: Wed Jul 21 21:35:15 2010 Checksum: 0x00012284 Comments: Thanks to Pierre-Alain Joye, Ilia Alshanetsky COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: enchant ISAPIFilter: False File Version: 5.3.3 Managed DLL: False Internal Name: ENCHANT extension VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php_enchant.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_enchant.dll Module name: php_enchant Private Build: Single Threaded: False Product Name: PHP Module Size: 32,00 KBytes Product Version: 5.3.3 Symbol File Name: php_enchant.dll Special Build: -- Edit this bug report at http://bugs.php.net/bug.php?id=53070edit=1
Bug #53070 [Fbk-Opn]: Calling enchant_broker_get_dict_path before set_path crashes php
Edit report at http://bugs.php.net/bug.php?id=53070edit=1 ID: 53070 User updated by:iwanluijks at gmail dot com Reported by:iwanluijks at gmail dot com Summary:Calling enchant_broker_get_dict_path before set_path crashes php -Status: Feedback +Status: Open Type: Bug Package:*Spelling functions Operating System: Windows 7 Home Premium PHP Version:5.3.3 Block user comment: N New Comment: Replaced the file as you requested, restarted Apache and running the file from CLI and Apache still crashed PHP. I was able to generate the following backtrace, seems to be different from the others (run 3 others before it to compare all and this is the only different one, as expected): Report for php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp Report for php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 3232 Process Image C:\PHP\php.exe System Up-Time 04:27:38 Process Up-Time 00:00:01 Thread 0 - System ID 4164 Entry point php+2dda Create time 14-10-2010 23:37:32 Time spent in user mode 0 Days 0:0:0.546 Time spent in kernel mode 0 Days 0:0:0.78 Function Arg 1 Arg 2 Arg 3 Source php_enchant!get_module+6f0 0001 695f0001 0x00c0fb30 695f0001 6e20736e PHP_ENCHANT!GET_MODULE+6F0WARNING - DebugDiag was not able to locate debug symbols for php_enchant.dll, so the information below may be incomplete. In php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!get_module+6f0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name: C:\PHP\ext\php_enchant.dll Symbol Type: Export Base address: 0x00d5 Time Stamp: Wed Jul 21 21:35:15 2010 Checksum: 0x00012284 Comments: Thanks to Pierre-Alain Joye, Ilia Alshanetsky COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: enchant ISAPIFilter: False File Version: 5.3.3 Managed DLL: False Internal Name: ENCHANT extension VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php_enchant.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_enchant.dll Module name: php_enchant Private Build: Single Threaded: False Product Name: PHP Module Size: 32,00 KBytes Product Version: 5.3.3 Symbol File Name: php_enchant.dll Special Build: Previous Comments: [2010-10-14 23:32:40] paj...@php.net Can you replace the libenchant.dll with libenchant_52841.zip, restart apache and try again please? http://windows.php.net/downloads/qa/test/libenchant_52841.zip Also please try using the CLI as well. [2010-10-14 23:15:30] fel...@php.net I can't reproduce it on linux. [2010-10-14 22:53:13] iwanluijks at gmail dot com Description: Whenever I try to call (the undocumented function) enchant_broker_get_dict_path before enchant_broker_set_dict_path my PHP instance crashes. My php.ini contains the following entries: enchant support enabled Version 1.1.0 Libenchant Version 1.5.0 or later Revision$Revision: 298870 $ ispellIspell Provider C:\PHP\libenchant_ispell.dll myspell Myspell Provider C:\PHP\libenchant_myspell.dll Test script: --- ?php $broker = enchant_broker_init(); enchant_broker_get_dict_path($broker, ENCHANT_ISPELL); ? Expected result: Either false because no dictionary path is set yet or an empty string or some kind. Actual result: -- Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Report for php__PID__892__Date__10_14_2010__Time_10_40_17PM__834__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 892 Process Image C:\PHP\php.exe System Up-Time 03:30:23 Process Up-Time 00:00:31 Thread 0 - System ID 5160 Entry point php+2dda Create time 14-10-2010 22:39:46 Time spent in user mode 0 Days 0:0:0.717 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source
Bug #53070 [Opn]: Calling enchant_broker_get_dict_path before set_path crashes php
Edit report at http://bugs.php.net/bug.php?id=53070edit=1 ID: 53070 User updated by:iwanluijks at gmail dot com Reported by:iwanluijks at gmail dot com Summary:Calling enchant_broker_get_dict_path before set_path crashes php Status: Open Type: Bug Package:*Spelling functions Operating System: Windows 7 Home Premium PHP Version:5.3.3 Block user comment: N New Comment: I just generated an extended backtrace: Report for php__PID__2596__Date__10_14_2010__Time_11_56_44PM__699__Second_Chance_Exception_C005.dmp Report for php__PID__2596__Date__10_14_2010__Time_11_56_44PM__699__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 2596 Process Image C:\PHP\php.exe System Up-Time 04:46:49 Process Up-Time 00:00:01 Thread 0 - System ID 1496 Entry point php!mainCRTStartup Create time 14-10-2010 23:56:43 Time spent in user mode 0 Days 0:0:0.452 Time spent in kernel mode 0 Days 0:0:0.140 Function Arg 1 Arg 2 Arg 3 Source php_enchant!zif_enchant_broker_get_dict_path+b0 0002 0249e2a8 php5!execute+cdf 024d0080 0249dc80 024d0080 php5!execute+4c25 00c0ebe8 00c0fe9c 00c0fc84 php5!execute+1f0 0249dc80 00c0fe9c php5!zend_execute_scripts+be 0008 0003 php5!php_execute_script+1e2 00c0fe9c 0040642c 0001 php!main+a9a 0003 025f1b10 025f1eb8 php!memcpy+160 7efde000 00c0ffd4 776f9d72 kernel32!BaseThreadInitThunk+e 7efde000 76ba527b ntdll!__RtlUserThreadStart+70 00402dda 7efde000 ntdll!_RtlUserThreadStart+1b 00402dda 7efde000 PHP_ENCHANT!ZIF_ENCHANT_BROKER_GET_DICT_PATH+B0In php__PID__2596__Date__10_14_2010__Time_11_56_44PM__699__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!zif_enchant_broker_get_dict_path+b0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name: C:\PHP\ext\php_enchant.dll Symbol Type: PDB Base address: 0x0244 Time Stamp: Wed Jul 21 21:35:15 2010 Checksum: 0x00012284 Comments: Thanks to Pierre-Alain Joye, Ilia Alshanetsky COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: enchant ISAPIFilter: False File Version: 5.3.3 Managed DLL: False Internal Name: ENCHANT extension VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php_enchant.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_enchant.dll Module name: php_enchant Private Build: Single Threaded: False Product Name: PHP Module Size: 32,00 KBytes Product Version: 5.3.3 Symbol File Name: C:\PHP\ext\php_enchant.pdb Special Build: Previous Comments: [2010-10-14 23:43:56] iwanluijks at gmail dot com Replaced the file as you requested, restarted Apache and running the file from CLI and Apache still crashed PHP. I was able to generate the following backtrace, seems to be different from the others (run 3 others before it to compare all and this is the only different one, as expected): Report for php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp Report for php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name IWANLUIJKS-PC Operating System Unexpected Number Of Processors 4 Process ID 3232 Process Image C:\PHP\php.exe System Up-Time 04:27:38 Process Up-Time 00:00:01 Thread 0 - System ID 4164 Entry point php+2dda Create time 14-10-2010 23:37:32 Time spent in user mode 0 Days 0:0:0.546 Time spent in kernel mode 0 Days 0:0:0.78 Function Arg 1 Arg 2 Arg 3 Source php_enchant!get_module+6f0 0001 695f0001 0x00c0fb30 695f0001 6e20736e PHP_ENCHANT!GET_MODULE+6F0WARNING - DebugDiag was not able to locate debug symbols for php_enchant.dll, so the information below may be incomplete. In php__PID__3232__Date__10_14_2010__Time_11_37_32PM__970__Second_Chance_Exception_C005.dmp the assembly instruction at php_enchant!get_module+6f0 in C:\PHP\ext\php_enchant.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Module Information Image Name:
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248edit=1 ID: 51248 Comment by: php at group dot apple dot com Reported by:mbecc...@php.net Summary:Segmentation fault in mysql_fetch_array Status: Feedback Type: Bug Package:MySQL related Operating System: FreeBSD 6.2 PHP Version:5.3.2 Assigned To:mysql Block user comment: N New Comment: Here are the configure flags I use: -- --with-apxs2=$(USRSBINDIR)/apxs \ --enable-cli \ --with-config-file-path=/etc \ --with-libxml-dir=$(USRDIR) \ --with-openssl=$(USRDIR) \ --with-kerberos=$(USRDIR) \ --with-zlib=$(USRDIR) \ --enable-bcmath \ --with-bz2=$(USRDIR) \ --enable-calendar \ --with-curl=$(USRDIR) \ --enable-exif \ --enable-ftp \ --with-gd \ --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \ --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \ --with-png-dir=$(DSTROOT)$(USRDIR)/local \ --enable-gd-native-ttf \ --with-ldap=$(USRDIR) \ --with-ldap-sasl=$(USRDIR) \ --enable-mbstring \ --enable-mbregex \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-mysql-sock=/var/mysql/mysql.sock \ --with-iodbc=$(USRDIR) \ --enable-shmop \ --with-snmp=$(USRDIR) \ --enable-soap \ --enable-sockets \ --enable-suhosin \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm \ --with-xmlrpc \ --with-iconv-dir=$(USRDIR) \ --with-xsl=$(USRDIR) \ --enable-zend-multibyte \ --enable-zip -- It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if it's modifying the crashing code in some way. In addition, I set CFLAGS=-Os -g -fstack-protector-all before calling configure. I will build again and see if I can tease out more information. Previous Comments: [2010-10-13 12:33:21] and...@php.net Again, no crash and...@vihren:~/dev/php5.3-201010130830 $ ./php a.php mysql version: 5.1.44 and...@vihren:~/dev/php5.3-201010130830 $ cat config.nice #! /bin/sh # # Created by configure CC='/usr/bin/llvm-gcc' \ './configure' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--disable-libxml' \ '--disable-dom' \ '--disable-simplexml' \ '--disable-xml' \ '--disable-xmlreader' \ '--disable-xmlwriter' \ '--without-pear' \ $@ and...@vihren:~/dev/php5.3-201010130830 $ uname -a Darwin vihren 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 The system is a MacOS X 10.6.something [2010-10-07 04:33:41] php at group dot apple dot com Thank you for attempting to reproduce on Mac OS X. The issue may be the choice of compiler, as the problem more readily reproduces with LLVM, which claims to be much more aggressive in its stack protection than GCC. One option would be to try to build using LLVM as the compiler, i.e.: CC=/usr/bin/llvm-gcc ./configure ... [2010-10-06 14:17:47] and...@php.net No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql. MySQL is 5.5.2 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all [2010-10-06 13:52:59] and...@php.net I get no crash on Ubuntu 9.10 x86, PHP 5.3.4-dev, MySQL 5.1.51 . Neither with libmysql nor with mysqlnd, but by looking at the stacktrace it should not matter much. Will get it checked on Mac OS 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=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248edit=1
Bug #53006 [Fbk-Asn]: stream_get_contents offset max is 1165
Edit report at http://bugs.php.net/bug.php?id=53006edit=1 ID: 53006 User updated by:poulpillusion at free dot fr Reported by:poulpillusion at free dot fr Summary:stream_get_contents offset max is 1165 -Status: Feedback +Status: Assigned Type: Bug Package:Streams related Operating System: Linux Aptosid PHP Version:5.3.3 Assigned To:cataphract Block user comment: N New Comment: You fixed it ! I assume this is your fix : http://svn.php.net/viewvc/php/php-src/trunk/main/streams/streams.c?r1=303414r2=304354 Even if you did all the work, I feel a little proud. Thank you very much, cataphract. Previous Comments: [2010-10-14 05:19:59] cataphr...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-10-14 05:15:19] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304384 Log: - [DOC] Reverted rev #304382 and rev #304380, as I figured out a way to fix the erratic behavior without breaking backwards compatibility. Namely, $offset retains SEEK_SET behavior but actually SEEK_CUR is passed to _php_stream_seek, if possible, by moving the offset stream-gt;position bytes. - Addresses bug #53006. [2010-10-14 04:03:20] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304380 Log: - [DOC] Changed stream_get_contents() so that the offset is relative to the current position (seek with SEEK_CUR, not SEEK_SET). Only positive values are allowed. This breaking change is necessary to fix the erratic behavior in streams without a seek handlder. Addresses bug #53006. #Note that the example on the doc page for stream_get_contents() may fail #without this change. #This change is also in the spirit of stream_get_contents(), whose description #is quot;Reads all remaining bytes (or up to maxlen bytes) from a stream...quot;. #Previous behavior allowed setting the file pointer to positions before the #current one, so they wouldn't be quot;remaining bytesquot;. The previous behavior was #also inconsistent in that it allowed an moving to offset 1, 2, ..., but not 0. [2010-10-13 23:59:37] poulpillusion at free dot fr Ok so... is there anything else I can do to help you fix this bug ? I mean : more testing, more feedback ? [2010-10-11 18:44:37] cataphr...@php.net There's definitely a bug here. However: * I couldn't reproduce any long blocking. The erroneous behavior was simply the (timely) return of an empty string from stream_get_contents. * In the network traffic dump, I couldn't find a FIN packet. PHP sent a RST right away. I tried with Debian Lenny, PHP 5.3.3 (CLI). 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=53006 -- Edit this bug report at http://bugs.php.net/bug.php?id=53006edit=1
[PHP-BUG] Bug #53071 [NEW]: Use of SPLObjectStorage Defeats gc_collect_cycles
From: Operating system: Windows XP PHP version: 5.3.3 Package: SPL related Bug Type: Bug Bug description:Use of SPLObjectStorage Defeats gc_collect_cycles Description: Using SPLObjectStorage objects in a cycle will defeat gc_collect_cycles ability to detect that cycle. So, if I have an object ParentObject which has an SPLObjectStorage which attaches a ChildObject that has a reference back to ParentObject, the garbage collector will never actually collect ParentObject. Expected result: After calling gc_collect_cycles() old objects that no longer have references should be collected Actual result: -- Cycles that have SPLObjectStorage in them are not collected -- Edit bug report at http://bugs.php.net/bug.php?id=53071edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53071r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53071r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53071r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53071r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53071r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53071r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53071r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53071r=needscript Try newer version: http://bugs.php.net/fix.php?id=53071r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53071r=support Expected behavior: http://bugs.php.net/fix.php?id=53071r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53071r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53071r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53071r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53071r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53071r=dst IIS Stability: http://bugs.php.net/fix.php?id=53071r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53071r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53071r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53071r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53071r=mysqlcfg
Bug #49148 [Com]: combination of stream_get_line and fseek does not work correctly
Edit report at http://bugs.php.net/bug.php?id=49148edit=1
ID: 49148
Comment by: arl at andrewrlevine dot com
Reported by:mugeso at mugeso dot com
Summary:combination of stream_get_line and fseek does not
work correctly
Status: Open
Type: Bug
Package:Streams related
Operating System: win32 only - Windows XP SP3
PHP Version:5.2.10
Block user comment: N
New Comment:
I can confirm this bug (on Ubuntu using PHP 5.2.10-2ubuntu6.5 with
Suhosin-Patch
0.9.7 (cli) (built: May 21 2010 06:30:21) )
Here is a workaround function I made that seems to work:
function stream_get_line_fixed($handle, $length, $ending) {
// Only allow 3 tries since if there's a genuine failure we don't
want to
loop forever
$tries = 3;
$ret = FALSE;
while ($ret === FALSE $tries--) {
$ret = stream_get_line($handle, $length, $ending);
}
return $ret;
}
Previous Comments:
[2009-08-31 20:04:38] garre...@php.net
This is reproduceable on Linux too.
[2009-08-04 07:44:16] mugeso at mugeso dot com
Description:
When use in combination of stream_get_line and fseek,
reading a file which has only 2 lines without ending on EOF(like below)
does fail.
This happens on only Windows and with only 2lines file without ending
on EOF.
Reproduce code:
---
2lines.txt
--
aCRLF
bEOF
phpfile:
--
?php
$file = dirname(__FILE__) . '/2lines.txt';
$fp = fopen($file, rb);
var_dump(stream_get_line($fp, null, \xd\xa));
fseek($fp, ftell($fp)); // expected that this does not affect result.
var_dump(stream_get_line($fp, null, \xd\xa));
Expected result:
string(1) a
string(1) b
Actual result:
--
string(1) a
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=49148edit=1
Bug #53071 [Com]: Use of SPLObjectStorage Defeats gc_collect_cycles
Edit report at http://bugs.php.net/bug.php?id=53071edit=1
ID: 53071
Comment by: chris dot crapo at bsci dot com
Reported by:chris dot crapo at bsci dot com
Summary:Use of SPLObjectStorage Defeats gc_collect_cycles
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows XP
PHP Version:5.3.3
Block user comment: N
New Comment:
//Cycle example:
class myClass
{
public $member;
}
function LimitedScope()
{
$myA = new myClass();
$myB = new SplObjectStorage();
$myC = new myClass();
$myC-member = $myA; // myC has a referece to myA
$myB-Attach($myC); // myB attaches myC
$myA-member = $myB; // myA has myB, comleting the cycle
}
echo Memory used: .$mem = memory_get_usage().\n;
echo Function Call\n;
LimitedScope();
echo Memory used: .memory_get_usage().\n;
echo Cycles culled: .gc_collect_cycles(). should be 1\n;
echo Memory used: .memory_get_usage(). should be {$mem};
Previous Comments:
[2010-10-15 01:14:53] chris dot crapo at bsci dot com
Description:
Using SPLObjectStorage objects in a cycle will defeat gc_collect_cycles
ability to detect that cycle.
So, if I have an object ParentObject which has an SPLObjectStorage which
attaches a ChildObject that has a reference back to ParentObject, the
garbage collector will never actually collect ParentObject.
Expected result:
After calling gc_collect_cycles() old objects that no longer have
references should be collected
Actual result:
--
Cycles that have SPLObjectStorage in them are not collected
--
Edit this bug report at http://bugs.php.net/bug.php?id=53071edit=1
Bug #53061 [Opn]: filesystem functions deal poorly with out of disk space conditions
Edit report at http://bugs.php.net/bug.php?id=53061edit=1
ID: 53061
User updated by:crrodriguez at opensuse dot org
Reported by:crrodriguez at opensuse dot org
Summary:filesystem functions deal poorly with out of disk
space conditions
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: *nix
PHP Version:5.3SVN-2010-10-14 (SVN)
Block user comment: N
New Comment:
A liltte bit better test case:
# dd if=/dev/zero of=/tmp/vfs bs=1024 count=1024
# losetup /dev/loop0 /tmp/vfs
# mkfs -t ext2 -m 1 -v /dev/loop0
# mkdir /mnt/vfs
# mount -t ext2 /dev/loop0 /mnt/vfs
?php
$fp = fopen('/mnt/vfs/foo.txt', 'wb');
var_dump(fwrite($fp, str_repeat(fail, 1024000)));
var_dump(fflush($fp));
var_dump(fclose($fp));
?
int(1003520)
bool(true)
bool(true)
ls -l /mnt/vfs/foo.txt
-rw-r--r-- 1 root root 1003520 oct 14 21:43 /mnt/vfs/foo.txt
Partial data on disk, no warning or return values hinting the problem.
Previous Comments:
[2010-10-14 07:00:13] cataphr...@php.net
Why would fflush return false? Nothing was written by fwrite, so the
flush is a no-op.
[2010-10-14 06:35:11] crrodriguez at opensuse dot org
Description:
Filesystem functions have IMHO the wrong behaviuor on disk-full
conditions
Test script:
---
?php
$fp = fopen('/dev/full', 'wb');
var_dump(fwrite($fp, fail));
var_dump(fflush($fp));
var_dump(fclose($fp));
Expected result:
bool(false) and warning ...No space left on device.. (aka, handle
ENOSPC)
bool(false)
bool(true)
Actual result:
--
int(0)
bool(true)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53061edit=1
Bug #53064 [Com]: filsize return 0 after is_file
Edit report at http://bugs.php.net/bug.php?id=53064edit=1 ID: 53064 Comment by: crrodriguez at opensuse dot org Reported by:mraaijmakers at gmail dot com Summary:filsize return 0 after is_file Status: Open Type: Bug Package:Filesystem function related Operating System: Linux Ubuntu PHP Version:5.2.14 Block user comment: N New Comment: Just for the sake of completeness, other than the already mentioned stale stat cache you are doing it wrong. fwrite does not imply fflush() and fclose() does not imply fsync() (and PHP does not fsync/fdatasync the file on close or provide direct functionality to do so unfortunately) Previous Comments: [2010-10-14 18:12:19] cataphr...@php.net read: negligible [2010-10-14 18:11:29] cataphr...@php.net That's just stale stat cache. This will work: ?php $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); clearstatcache(false, $filename); var_dump($isFile, file_get_contents($filename), filesize($filename)); I'm not closing because maybe there's a way to invalidate the cache for that file with a negligent performance penalty. [2010-10-14 08:38:22] mraaijmakers at gmail dot com Description: When using is_file() on a file which is open via fopen(), the filesize() function returns 0, even after fclose() is called; see test script. Test script: --- $filename = dirname(__FILE__) . '/test.txt'; $fh = fopen($filename, 'w+'); $isFile = is_file($filename); fwrite($fh, 'some data goes here!'); fclose($fh); var_dump($isFile, file_get_contents($filename), filesize($filename)); Expected result: boolean true string 'some data goes here!' (length=20) int 20 Actual result: -- boolean true string 'some data goes here!' (length=20) int 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53064edit=1
Req #49542 [Com]: __callStatic() only invoked if instance method does not exist
Edit report at http://bugs.php.net/bug.php?id=49542edit=1
ID: 49542
Comment by: matt dot lubner at gmail dot com
Reported by:mjs at beebo dot org
Summary:__callStatic() only invoked if instance method does
not exist
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Ubuntu
PHP Version:5.3.0
Block user comment: N
New Comment:
With PHP 5.3.2, if the instance method bar() is *not* public, and
__callStatic()
*is*, __callStatic() will be invoked, because bar() won't be in scope.
Unfortunately, this seems like a horribly hacked work-around. Ideally,
public
instance methods should not be in scope from a static context, so
__callStatic()
will be called instead.
Previous Comments:
[2009-09-13 14:34:38] mjs at beebo dot org
Description:
A static call to Foo::bar() does not invoke __callStatic() if an
instance method bar() exists.
One reason you might want this is to convert static calls to Foo::bar()
to the equivalent operation on a singleton:
public static function __callStatic($name, $args) {
$obj = self::getInstance();
return call_user_func_array(array($obj, $name), $args);
}
In the sample code below, __callStatic() is not invoked even though the
caller has deliberately initiated a static call.
Reproduce code:
---
?php
class Foo {
public static function __callStatic($name, $args) {
echo In __callStatic()\n;
}
public function bar() {
echo In bar()\n;
}
}
echo Foo::bar();
Expected result:
In _callStatic()
Actual result:
--
PHP Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
In bar()
--
Edit this bug report at http://bugs.php.net/bug.php?id=49542edit=1
Req #49542 [Com]: __callStatic() only invoked if instance method does not exist
Edit report at http://bugs.php.net/bug.php?id=49542edit=1
ID: 49542
Comment by: matt dot lubner at gmail dot com
Reported by:mjs at beebo dot org
Summary:__callStatic() only invoked if instance method does
not exist
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Ubuntu
PHP Version:5.3.0
Block user comment: N
New Comment:
I should have also mentioned that calling an instance method in a static
context
does not generate an error, unless the called method has any references
to $this
(which of course is not in scope), in which case a fatal error occurs.
This can
be a little tricky to track down, and so would be preferable if instance
methods
were simply not in scope for static contexts.
Previous Comments:
[2010-10-15 03:40:41] matt dot lubner at gmail dot com
With PHP 5.3.2, if the instance method bar() is *not* public, and
__callStatic()
*is*, __callStatic() will be invoked, because bar() won't be in scope.
Unfortunately, this seems like a horribly hacked work-around. Ideally,
public
instance methods should not be in scope from a static context, so
__callStatic()
will be called instead.
[2009-09-13 14:34:38] mjs at beebo dot org
Description:
A static call to Foo::bar() does not invoke __callStatic() if an
instance method bar() exists.
One reason you might want this is to convert static calls to Foo::bar()
to the equivalent operation on a singleton:
public static function __callStatic($name, $args) {
$obj = self::getInstance();
return call_user_func_array(array($obj, $name), $args);
}
In the sample code below, __callStatic() is not invoked even though the
caller has deliberately initiated a static call.
Reproduce code:
---
?php
class Foo {
public static function __callStatic($name, $args) {
echo In __callStatic()\n;
}
public function bar() {
echo In bar()\n;
}
}
echo Foo::bar();
Expected result:
In _callStatic()
Actual result:
--
PHP Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
In bar()
--
Edit this bug report at http://bugs.php.net/bug.php?id=49542edit=1
[PHP-BUG] Bug #53072 [NEW]: Pspell does not work with RoundCube
From: Operating system: Windows Server 2003 PHP version: 5.2.14 Package: Pspell related Bug Type: Bug Bug description:Pspell does not work with RoundCube Description: Pspell does not work with PHP 5.2.14. I have tried swapping the DLL from 5.2.13-5.2.10 but I get the same results. No errors. It just does nothing. Tried with Apache 2.2.14-2.2.16 Works with PHP 5.2.6. -- Edit bug report at http://bugs.php.net/bug.php?id=53072edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53072r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53072r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53072r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53072r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53072r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53072r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53072r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53072r=needscript Try newer version: http://bugs.php.net/fix.php?id=53072r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53072r=support Expected behavior: http://bugs.php.net/fix.php?id=53072r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53072r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53072r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53072r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53072r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53072r=dst IIS Stability: http://bugs.php.net/fix.php?id=53072r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53072r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53072r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53072r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53072r=mysqlcfg
Req #17060 [Com]: Request: localization of strtotime
Edit report at http://bugs.php.net/bug.php?id=17060edit=1 ID: 17060 Comment by: RReverser at gmail dot com Reported by:giank at geginformatica dot it Summary:Request: localization of strtotime Status: Closed Type: Feature/Change Request Package:Feature/Change Request Operating System: Red Hat 7.1 PHP Version:4.2.0 Block user comment: N New Comment: I want to propose simple solution for this problem: http://www.phpclasses.org/package/6551-PHP-Manipulating-with-localized-date-time-strings.html Previous Comments: [2002-05-08 21:41:09] giank at geginformatica dot it Bogus. [2002-05-07 10:02:12] giank at geginformatica dot it I think behaving on locale could trigger compatibility problems. [2002-05-07 09:48:36] giank at geginformatica dot it int strtotime ( string time [, int now]) is the actual function. As it gets even a complex input from the string time, I think it's difficult to emulate these functionality in a localized fashion. However, much of the international users are concerned about the output of the function. That could be modified without such a difficulty. Here's a proposal int strtotime ( string time [, int now] [, string ccode]) where the optional string ccode handles the localization request. Giving IT the result will be in Italian, EN or US for plain English, DE for German, FR for French and so on. So when requesting a date string, outputting in French, the software only has to know the country specific position of the substrings week, month, day, year and the name of weeks and months in that language. This could not work for other calendar dates, as chinese. Submitting 10+ languages could be a matter of hours work, and backward compatibility should not be an issue, as the parameter ccode is optional. This could be a little step for the PHP source code, but a big step for the PHP community worldwide. [2002-05-07 00:24:23] ras...@php.net Not silly, just not all that easy to do. Changed to feature request. [2002-05-06 22:36:16] giank at geginformatica dot it As the function strtotime only returns dates using the english names for the months and weeks, why not make it more customizable, making it possible to return dates in other languages? As of now, it could be got much much useful. Thanks in advance, and excuse me if this seems a silly request. -- Edit this bug report at http://bugs.php.net/bug.php?id=17060edit=1
