Bug #51126 [Com]: class_exists + namespaces
Edit report at https://bugs.php.net/bug.php?id=51126&edit=1
ID: 51126
Comment by: php dot net at jluis dot com dot ar
Reported by:richard at rjharrison dot org
Summary:class_exists + namespaces
Status: Not a bug
Type: Bug
Package:SPL related
Operating System: linux
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
I have a very similar problem, not with class exists, but with dynamic
instantiation:
return ($dynamic? new $className : new SelectMysql);
I can fix it concatenating __NAMESPACE__, but it seems weird that PHP cannot
determine this.
Here's a working example:
Select.php
SelectMysql.php
test.php
Previous Comments:
[2011-10-10 10:37:50] dmittner at llnw dot com
I agree that this behavior is counter-intuitive. I seem to have just run into
the same problem, myself, where my autoload works just fine where
class_exists() returns false.
In short... class_exists() should really infer the given namespace of the
current file, just like it's inferred in all other uses.
[2010-02-23 19:02:17] richard at rjharrison dot org
Hi Johannes,
I double-checked the documentation and found no mention that the string passed
to class_exists() must be fully qualified. Perhaps this is a documentation bug.
It is certainly seems inconsistent/counter-intuitive:-
class_exists('Things\Car'); // FALSE, class does not exist
$car = new Things\Car(); // HUH? Class does exist after all
So PHP is able to figure out there is a "use Foo/Things" namespace in effect on
one line, but not on the other? Lame.
[2010-02-23 18:46:01] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When used as a string we need the fully qualified name as we don't know where
the parameter is coming from.
[2010-02-23 18:41:57] richard at rjharrison dot org
Description:
class_exists() is not calling my spl_autoload_register'ed function with a fully
qualified (namespaced) class name.
Because the input to my autoload function is not fully qualified, it cannot
load the class and class_exists return false; however, if I try to instantiate
the class that "does not exist" then the correct, fully qualified class now
passed to the autoloader: it correctly loads the class and my code works.
Reproduce code:
---
// register my autoloader
use Foo\Things;
// This fails: my autoload function is called with $class = 'Things\Car'
if(class_exists('Things\Car')){
echo "class exists!";
}else{
echo "Weird?";
}
// This works: my autoload function is called with $class = 'Foo\Things\Car'
$x = new Things\Car();
Expected result:
"class exists!"
Actual result:
--
"Weird?"
--
Edit this bug report at https://bugs.php.net/bug.php?id=51126&edit=1
Bug #60977 [Opn->Csd]: number_format behavior changed when passing \0 for 4th parameter.
Edit report at https://bugs.php.net/bug.php?id=60977&edit=1 ID: 60977 User updated by:chobie...@php.net Reported by:chobie...@php.net Summary:number_format behavior changed when passing \0 for 4th parameter. -Status: Open +Status: Closed Type: Bug Package:Math related Operating System: OSX PHP Version:5.4.0RC7 Block user comment: N Private report: N New Comment: see https://bugs.php.net/bug.php?id=62112 Previous Comments: [2012-05-09 01:21:08] ahar...@php.net I'm sorry, I don't have any time for PHP work for the forseeable future. Unassigning myself. @clowns: Presumably you don't understand the concept of a code freeze. [2012-05-08 21:42:07] clowns at hotmail dot com "I don't think this is going to be considered serious enough" You mean making PHP thinks 100 equals to 1 is not a serious bug? Do you know how many extensions/plugins uses number_format on number larger than 999? What a joke. [2012-05-08 21:35:05] dslgjkdg at hotmail dot com 3 months later, any news on the fix? This bug makes phpredis zadd useless: https://github.com/nicolasff/phpredis/issues/113 [2012-02-06 00:46:14] ahar...@php.net Ouch, this one's my fault, as it came in with the fix for request #53457 in revision 305937. (char) 0 was previously used to signal no separator, whereas now the lack of a separator actually signals no separator. Unfortunately, I didn't take into account that _php_math_number_format() returns a C string, and is hence null-terminated as a result. The right fix here (which I'll work up and commit to trunk) is to change _php_math_number_format() and _php_math_number_format_ex() to return a zval, or at least have some other way of signalling the string length to the caller. Unfortunately, as this would break the ABI, about the best I can do for 5.4 is to emulate the old behaviour when the decimal point or thousands separator includes a null byte (which is to ignore it altogether: the 5.3 output doesn't actually include any nulls). I don't think this is going to be considered serious enough to be included in 5.4.0, given we're in code freeze, but I'll put together a patch and attach it here before committing it post-5.4.0. [2012-02-04 16:58:37] php-dev at zerocue dot com This is interesting, I would think that the 5_4 functionality is more correct, because you're adding a null character as the thousands separator so the string is becoming: 1\0328\0370\0011.7238 Internally a null character terminates a C style string. I would think the appropriate fix would be to limit the fourth parameter to displayable characters. This probably changed as a result of a bugfix somewhere. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60977 -- Edit this bug report at https://bugs.php.net/bug.php?id=60977&edit=1
Bug #62300 [Opn]: Wrong NULL checks
Edit report at https://bugs.php.net/bug.php?id=62300&edit=1 ID: 62300 User updated by:qiyuhua at 126 dot com Reported by:qiyuhua at 126 dot com Summary:Wrong NULL checks Status: Open Type: Bug Package:InterBase related Operating System: ubuntu 10.04 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: I have updated the patch file. Test to reproduce the bug : 1.Create a table with not null field 2.Add trigger filling this field before insert 3.Try from PHP insert null value in the way of "ibase_query($dbh, "insert into hua values (3,?)",null)", which is the key for the reproduction. And if we insert null value in the way of "ibase_query($dbh, "insert into hua values (3,null)")", there is no error. Previous Comments: [2012-06-12 23:23:26] fel...@php.net Please, send a unified diff next time. Thanks. [2012-06-12 13:00:42] qiyuhua at 126 dot com Description: As described in https://bugs.php.net/bug.php?id=54426, Wrong NULL checks was found. However, we find that the bug is not well repaired. And we can still reproduce the bug. Removing the "continue" statement in the block of Null check code in ibase_query.c should be make everything work well: Modified: php/php-src/trunk/ext/interbase/ibase_query.c === 679c679 < continue; --- > //continue; === Test script: --- The two simple test scripts can be available at https://sourceforge.net/projects/wautorepair/files/test%20cases/ 1)create a table like "createtable.php"; 2)insert a NULL value like "huahua.php" then, some errors will occur. -- Edit this bug report at https://bugs.php.net/bug.php?id=62300&edit=1
[PHP-BUG] Bug #62337 [NEW]: Randomly getting exhausted memory
From: jrbasso at gmail dot com
Operating system: Linux 3.2.12-3.2.4.amzn1.x86_64
PHP version: 5.3.14
Package: SOAP related
Bug Type: Bug
Bug description:Randomly getting exhausted memory
Description:
Randomly the SoapClient constructor is trying to allocate huge amounts of
memory
and causing the error Error: Allowed memory size of 268435456 bytes
exhausted
(tried to allocate 18446744072233156736 bytes)
The amount goes from 2GB to numbers like above.
This started to happen when we switched from 5.3.10 to 5.3.13 (and now
5.3.14).
I am not able to reproduce the error easily, once it do not happens in all
the
requests. The constructor is always called with the same parameters.
Soap configuration:
Soap Client enabled
Soap Server enabled
Directive Local Value
soap.wsdl_cache 1
soap.wsdl_cache_dir /tmp
soap.wsdl_cache_enabled 1
soap.wsdl_cache_limit 5
soap.wsdl_cache_ttl 86400
Test script:
---
$soap = new
SoapClient('https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.47.wsdl',
array('merchantId' => '???', 'transactionKey' => '???'));
--
Edit bug report at https://bugs.php.net/bug.php?id=62337&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62337&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62337&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62337&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62337&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62337&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62337&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62337&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62337&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62337&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62337&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62337&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62337&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62337&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62337&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62337&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62337&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62337&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62337&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62337&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62337&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62337&r=mysqlcfg
Bug #60512 [Com]: pdo_dblib - Seg Fault error on user/pass exceeds 30 chars
Edit report at https://bugs.php.net/bug.php?id=60512&edit=1
ID: 60512
Comment by: bmherold at gmail dot com
Reported by:paul dot visco at roswellpark dot org
Summary:pdo_dblib - Seg Fault error on user/pass exceeds 30
chars
Status: Open
Type: Bug
Package:PDO related
Operating System: Centos 5.5/Fedora 16
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Created a gist of my crash log at: https://gist.github.com/2938986
Previous Comments:
[2012-06-15 22:06:01] bmherold at gmail dot com
Has there been any movement on this bug? I'm using freetds 0.91 on OS X 10.7.4
and
php 5.3.13. HTTPD crashes when using a password of over 30 characters as seen
in
the console logs. I can also tail freetds.log and it doesnt even make it in
here -
but only when the password is over 30 chars.
[2011-12-13 16:21:35] paul dot visco at roswellpark dot org
Description:
LIB: freetds-0.91-1
PHP: php 5.3.8
EXT: pdo_dblib from /ext folder of php 5.3.8 source
OS: Fedora 16/Centos 5
I was using pdo_dblib to connect to a MSSQL server db. When the password or
username is longer than 30 chars, a segmentation fault occurrs, crashing PHP.
It would be ideal to instead throw the catchable error from freetds which is
"20042 Name too long for LOGINREC field (severity 2)"
The problem is that the code is not checking to make sure dbproc is not NULL
before processing the error info further. In the case of the password being
longer than 30 chars it is NULL, which then causes the seg fault.
Test script:
---
$db = new PDO("dblib:host=someserver;", "uname",
'31charpasswordpasswordpasswordp');
Expected result:
20042 Name too long for LOGINREC field (severity 2)
Actual result:
--
segmentation fault
OUTPUT FROM gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
(gdb) bt
#0 0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
#1 0x003905079b3c in strerror_r () from /lib64/libc.so.6
#2 0x00390507997e in strerror () from /lib64/libc.so.6
#3 0x2aaab26a6815 in ?? () from /usr/lib64/libsybdb.so.5
#4 0x2aaab26a7aa9 in dbgetuserdata () from /usr/lib64/libsybdb.so.5
#5 0x2aaab3bc2c59 in error_handler (dbproc=0x39051200a9,
severity=85066262, dberr=0, oserr=0, dberrstr=0x0, oserrstr=0x5 )
at /home/ROSWELL/visco/php-5.3.8/ext/pdo_dblib/pdo_dblib.c:98
--
Edit this bug report at https://bugs.php.net/bug.php?id=60512&edit=1
Bug #60512 [Com]: pdo_dblib - Seg Fault error on user/pass exceeds 30 chars
Edit report at https://bugs.php.net/bug.php?id=60512&edit=1
ID: 60512
Comment by: bmherold at gmail dot com
Reported by:paul dot visco at roswellpark dot org
Summary:pdo_dblib - Seg Fault error on user/pass exceeds 30
chars
Status: Open
Type: Bug
Package:PDO related
Operating System: Centos 5.5/Fedora 16
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Has there been any movement on this bug? I'm using freetds 0.91 on OS X 10.7.4
and
php 5.3.13. HTTPD crashes when using a password of over 30 characters as seen
in
the console logs. I can also tail freetds.log and it doesnt even make it in
here -
but only when the password is over 30 chars.
Previous Comments:
[2011-12-13 16:21:35] paul dot visco at roswellpark dot org
Description:
LIB: freetds-0.91-1
PHP: php 5.3.8
EXT: pdo_dblib from /ext folder of php 5.3.8 source
OS: Fedora 16/Centos 5
I was using pdo_dblib to connect to a MSSQL server db. When the password or
username is longer than 30 chars, a segmentation fault occurrs, crashing PHP.
It would be ideal to instead throw the catchable error from freetds which is
"20042 Name too long for LOGINREC field (severity 2)"
The problem is that the code is not checking to make sure dbproc is not NULL
before processing the error info further. In the case of the password being
longer than 30 chars it is NULL, which then causes the seg fault.
Test script:
---
$db = new PDO("dblib:host=someserver;", "uname",
'31charpasswordpasswordpasswordp');
Expected result:
20042 Name too long for LOGINREC field (severity 2)
Actual result:
--
segmentation fault
OUTPUT FROM gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
(gdb) bt
#0 0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
#1 0x003905079b3c in strerror_r () from /lib64/libc.so.6
#2 0x00390507997e in strerror () from /lib64/libc.so.6
#3 0x2aaab26a6815 in ?? () from /usr/lib64/libsybdb.so.5
#4 0x2aaab26a7aa9 in dbgetuserdata () from /usr/lib64/libsybdb.so.5
#5 0x2aaab3bc2c59 in error_handler (dbproc=0x39051200a9,
severity=85066262, dberr=0, oserr=0, dberrstr=0x0, oserrstr=0x5 )
at /home/ROSWELL/visco/php-5.3.8/ext/pdo_dblib/pdo_dblib.c:98
--
Edit this bug report at https://bugs.php.net/bug.php?id=60512&edit=1
[PHP-BUG] Bug #62336 [NEW]: PHPSESSID changes when access another page
From: adelsontads at gmail dot com Operating system: Linux web525.kinghost.net 3.1.4 PHP version: Irrelevant Package: Session related Bug Type: Bug Bug description:PHPSESSID changes when access another page Description: I made a authorization system that works locally, but when you put into the server in production happens the change of the PHPSESSID value when I change page. All the data are lost on this page, but when I return to the previous page back PHPSESSID the right value. Works locally, why there? Locally this change does not occur because? how do I keep the same PHPSESSID while logged in? -- Edit bug report at https://bugs.php.net/bug.php?id=62336&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62336&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62336&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62336&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62336&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62336&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62336&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62336&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62336&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62336&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62336&r=support Expected behavior: https://bugs.php.net/fix.php?id=62336&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62336&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62336&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62336&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62336&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62336&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62336&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62336&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62336&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62336&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62336&r=mysqlcfg
Bug #49625 [Com]: spl_autoload and case sensitivity
Edit report at https://bugs.php.net/bug.php?id=49625&edit=1
ID: 49625
Comment by: jdornan at stanford dot edu
Reported by:jo at feuersee dot de
Summary:spl_autoload and case sensitivity
Status: Not a bug
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
This seems like a 20 min fix to me, and I've never looked the sql_autoload code
before. I spent a good deal of time spinning my wheels on this. I don't see why
anyone should lose time of this very obvious bug. However it's better to patch
that to bitch, as I always say. I'll submit my patch and see what happens. It's
not big deal if this is not fixed, since it's so easy to fix I can keep fixing
it with each release.
Here is a diff, I'll submit the patch with the "Add a Patch" link.
225d224
< char *lc_class_file;
227d225
< int lc_class_file_len;
229d226
< int mixed_case = 0;
235,236c232
< lc_class_file_len = spprintf(&lc_class_file, 0, "%s%s", lc_name,
file_extension);
< class_file_len = spprintf(&class_file, 0, "%s%s", class_name,
file_extension);
---
> class_file_len = spprintf(&class_file, 0, "%s%s", lc_name,
file_extension);
252,261c248
< mixed_case = 1;
< }
<
< /* fall back to lowercase file name. should issue deprecated warning.
*/
< if (ret != SUCCESS) {
< ret = php_stream_open_for_zend_ex(lc_class_file, &file_handle,
ENFORCE_SAFE_MODE|USE_PATH|STREAM_OPEN_FOR_INCLUDE TSRMLS_CC);
< }
<
< if (ret == SUCCESS) {
< if (!file_handle.opened_path && mixed_case == 1) {
---
> if (!file_handle.opened_path) {
263,264d249
< } else if(!file_handle.opened_path && mixed_case == 0) {
< file_handle.opened_path = estrndup(lc_class_file,
lc_class_file_len);
290d274
< efree(lc_class_file);
295d278
< efree(lc_class_file);
331d313
<
PS: I really hate this bug with a passion.
Previous Comments:
[2012-06-01 23:10:39] mrex at interport dot net
After having lost 2 days over this, I agree, this should be fixed. At the very
least, it should be documented that spl_autoload lower cases filenames. I
spent hours trying to register an autoload class that would fix this, but in
vain. How can I know that "dataloader" should be mapped to "DataLoader"?
If it had been documented that filenames were lowercased, I would not have
spent hours banging my head against a brick wall...
[2012-05-14 23:45:55] david at panmedia dot co dot nz
Please fix this
[2011-09-05 01:32:08] blake dot soley at gmail dot com
I agree, this bug is not bogus. In fact, it's actually quite serious. Just
because spl_autoload was designed poorly doesn't mean it has to remain broken.
Several fixes have been proposed, please consider implementing one of them to
make this function cross-platform, and therefore useful.
[2011-08-10 01:13:40] bram048 at gmail dot com
I agree with Simon. There is absolutely no reason not to fix this, while
keeping
backwards compatibility.
Two years ago the reason for not fixing it was "breaking BC is not an option".
There are plenty of alternatives, and to be honest, PHP has broken BC alot of
times in the last few versions (which is a good thing in my opinion, as long as
the language becomes cleaner/stricter).
Having all the files in lowercase makes them alot harder to read. Having a
custom autoloader function is slower and more complicated to get right, and
just
makes code more ugly and harder to understand.
At the very least case sensitivity of the SPL autoloader should be
configurable,
or available by the use of an extra suffix. I would love to see this in the new
5.4 release; shouldn't take more than a few lines of code.
[2011-03-08 13:08:42] simon at systemparadox dot co dot uk
Why is this bug marked as bogus?
Even if spl_autoload itself isn't fixed, at the very least a version that does
it correctly could be added (although in this case it seriously could just be
fixed by trying the correct case first).
Implementing one in PHP is all very well, but that means that it's non-standard
and likely incompatible with what each programmer might expect. It's also
slower.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php
Bug #62335 [Com]: zlib conflict with gzhandler
Edit report at https://bugs.php.net/bug.php?id=62335&edit=1
ID: 62335
Comment by: mtanalin at yandex dot ru
Reported by:hajo at csphere dot eu
Summary:zlib conflict with gzhandler
Status: Open
Type: Bug
Package:Zlib related
Operating System: Windows 7
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Same error for me with this code:
ob_start('ob_gzhandler');
Windows 7, Apache 2.4, PHP 5.4.4 thread-safe, "zlib.output_compression" is set
to "off" in php.ini.
The bug disappears if I add "php_flag zlib.output_compression off" in .htaccess
file of specific host. So, probably, the bug is that global (from php.ini)
"zlib.output_compression=off" setting is just _ignored_ in PHP 5.4.4.
Previous Comments:
[2012-06-15 14:50:54] hajo at csphere dot eu
update: the issue always starts on first refresh, so it might be caused by the
fix for bug 60761, just guessing.
[2012-06-15 14:35:03] hajo at csphere dot eu
there is also a second error message, but that might be clear:
ob_start(): failed to create buffer
[2012-06-15 14:32:28] hajo at csphere dot eu
Description:
with php 5.3.13, 5.3.14 and 5.4.3 the script is working well while it delivers
the following error with php 5.4.4:
ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output
compression'
webserver is nginx 1.2 without deflate mods using php via fcgi
php.ini setting 'zlib.output_compression' is turned off
Test script:
---
error_reporting(E_ALL);
$zlib_oc = ini_get('zlib.output_compression');
if(empty($zlib_oc)) {
ob_start('ob_gzhandler');
}
echo 'test';
Expected result:
test
Actual result:
--
test with the error message attached that was mentioned above
--
Edit this bug report at https://bugs.php.net/bug.php?id=62335&edit=1
Bug #62313 [Com]: Zend\tests\errmsg_021.phpt fails
Edit report at https://bugs.php.net/bug.php?id=62313&edit=1 ID: 62313 Comment by: a...@php.net Reported by:a...@php.net Summary:Zend\tests\errmsg_021.phpt fails Status: Open Type: Bug Package:Reproducible crash Operating System: windows PHP Version:5.4Git-2012-06-13 (snap) Block user comment: N Private report: N New Comment: the patch was updated to exlude zend_disable_class only from optimization Previous Comments: [2012-06-15 15:52:55] a...@php.net The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339775574 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339775574 [2012-06-15 10:38:28] paj...@php.net Disable optimization for the new handler is going to kill many perf improvements in 5.4+. I am sure the issue occurs later on, inside the error management or the ini fetching code. But I cannot let this patch in as it is now, disabling optimization for new is no-no :) [2012-06-15 09:39:27] a...@php.net The fail seems to be caused only in builds using PGO, the patch disables it for the relevant place. [2012-06-15 09:38:28] a...@php.net The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339753108 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339753108 [2012-06-13 11:46:49] a...@php.net Description: Test diff: 002- Done What is really going on behind the scenes is a crash. The strange thing here is - it fails only on the snapshots, running the test on a self compiled binary passes. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=62313&edit=1
Bug #62313 [PATCH]: Zend\tests\errmsg_021.phpt fails
Edit report at https://bugs.php.net/bug.php?id=62313&edit=1 ID: 62313 Patch added by: a...@php.net Reported by:a...@php.net Summary:Zend\tests\errmsg_021.phpt fails Status: Open Type: Bug Package:Reproducible crash Operating System: windows PHP Version:5.4Git-2012-06-13 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339775574 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339775574 Previous Comments: [2012-06-15 10:38:28] paj...@php.net Disable optimization for the new handler is going to kill many perf improvements in 5.4+. I am sure the issue occurs later on, inside the error management or the ini fetching code. But I cannot let this patch in as it is now, disabling optimization for new is no-no :) [2012-06-15 09:39:27] a...@php.net The fail seems to be caused only in builds using PGO, the patch disables it for the relevant place. [2012-06-15 09:38:28] a...@php.net The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339753108 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339753108 [2012-06-13 11:46:49] a...@php.net Description: Test diff: 002- Done What is really going on behind the scenes is a crash. The strange thing here is - it fails only on the snapshots, running the test on a self compiled binary passes. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=62313&edit=1
Bug #62236 [Fbk->Opn]: Hardcoded path /usr/local/bin/php
Edit report at https://bugs.php.net/bug.php?id=62236&edit=1 ID: 62236 User updated by:max dot antonoff at gmail dot com Reported by:max dot antonoff at gmail dot com Summary:Hardcoded path /usr/local/bin/php -Status: Feedback +Status: Open Type: Bug Package:CGI/CLI related Operating System: Linux -PHP Version:5.4.4RC2 +PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Seems fixed: which php; which pear; php -v; php -i |grep configure; pear list-all |grep XML_svg2image /home/max/local/bin/php /home/max/local/bin/pear PHP 5.4.4 (cli) (built: Jun 15 2012 18:47:49) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Configure Command => './configure' '--prefix=/home/max/local' '--disable-cgi' '--with-pear=/home/max/local/PEAR' pear/XML_svg2image 0.2.0Converts a svg file to a png/jpeg image. Previous Comments: [2012-06-15 11:37:29] maar...@php.net Max, could you please try/test the above hint? [2012-06-11 12:59:53] Sjon at hortensius dot net /usr/bin/pear is a simple script that determines which PHP binary to use. It should be easy to debug this yourself, I think an incorrect $PHP_PEAR_PHP_BIN might cause this for example [2012-06-05 20:04:05] max dot antonoff at gmail dot com Description: max 23:58:24 php-src $ pear list-all exec: 28: /usr/local/bin/php: not found max 23:58:15 php-src $ php -v PHP 5.4.4-RC2 (cli) (built: Jun 5 2012 23:48:00) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies max 23:58:29 php-src $ which php ; which pear; php -i |grep configure /home/max/local/bin/php /home/max/local/bin/pear Configure Command => './configure' '--prefix=/home/max/local' '--enable-proxy' '--disable-cgi' '--with-mysqli' '--enable-fpm' '--with-fpm-user=max' '--with- fpm-group=max' '--with-config-file-path=/home/max/local/etc/php.ini' '--with- config-file-scan-dir=/home/max/local/etc/php.d' '--enable-sigchild' '--disable- ipv6' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath' '-- with-bz2' '--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp' '-- with-gd' '--enable-gd-native-ttf' '--with-mhash' '--enable-mbstring' '--with- mcrypt' '--with-mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '-- enable-pcntl' '--with-pdo-mysql' '--enable-shmop' '--enable-soap' '--enable- sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable- wddx' '--with-xsl' '--enable-zip' '--enable-mysqlnd' '--with- pear=/home/max/local/PEAR' '--with-jpeg-dir' '--with-png-dir' '--enable-intl' Test script: --- max 23:58:24 php-src $ pear list-all Expected result: list of packages Actual result: -- exec: 28: /usr/local/bin/php: not found -- Edit this bug report at https://bugs.php.net/bug.php?id=62236&edit=1
Bug #62335 [Opn]: zlib conflict with gzhandler
Edit report at https://bugs.php.net/bug.php?id=62335&edit=1
ID: 62335
User updated by:hajo at csphere dot eu
Reported by:hajo at csphere dot eu
Summary:zlib conflict with gzhandler
Status: Open
Type: Bug
Package:Zlib related
Operating System: Windows 7
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
update: the issue always starts on first refresh, so it might be caused by the
fix for bug 60761, just guessing.
Previous Comments:
[2012-06-15 14:35:03] hajo at csphere dot eu
there is also a second error message, but that might be clear:
ob_start(): failed to create buffer
[2012-06-15 14:32:28] hajo at csphere dot eu
Description:
with php 5.3.13, 5.3.14 and 5.4.3 the script is working well while it delivers
the following error with php 5.4.4:
ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output
compression'
webserver is nginx 1.2 without deflate mods using php via fcgi
php.ini setting 'zlib.output_compression' is turned off
Test script:
---
error_reporting(E_ALL);
$zlib_oc = ini_get('zlib.output_compression');
if(empty($zlib_oc)) {
ob_start('ob_gzhandler');
}
echo 'test';
Expected result:
test
Actual result:
--
test with the error message attached that was mentioned above
--
Edit this bug report at https://bugs.php.net/bug.php?id=62335&edit=1
Bug #62335 [Opn]: zlib conflict with gzhandler
Edit report at https://bugs.php.net/bug.php?id=62335&edit=1
ID: 62335
User updated by:hajo at csphere dot eu
Reported by:hajo at csphere dot eu
Summary:zlib conflict with gzhandler
Status: Open
Type: Bug
Package:Zlib related
Operating System: Windows 7
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
there is also a second error message, but that might be clear:
ob_start(): failed to create buffer
Previous Comments:
[2012-06-15 14:32:28] hajo at csphere dot eu
Description:
with php 5.3.13, 5.3.14 and 5.4.3 the script is working well while it delivers
the following error with php 5.4.4:
ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output
compression'
webserver is nginx 1.2 without deflate mods using php via fcgi
php.ini setting 'zlib.output_compression' is turned off
Test script:
---
error_reporting(E_ALL);
$zlib_oc = ini_get('zlib.output_compression');
if(empty($zlib_oc)) {
ob_start('ob_gzhandler');
}
echo 'test';
Expected result:
test
Actual result:
--
test with the error message attached that was mentioned above
--
Edit this bug report at https://bugs.php.net/bug.php?id=62335&edit=1
[PHP-BUG] Bug #62335 [NEW]: zlib conflict with gzhandler
From: hajo at csphere dot eu
Operating system: Windows 7
PHP version: 5.4.4
Package: Zlib related
Bug Type: Bug
Bug description:zlib conflict with gzhandler
Description:
with php 5.3.13, 5.3.14 and 5.4.3 the script is working well while it
delivers the following error with php 5.4.4:
ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output
compression'
webserver is nginx 1.2 without deflate mods using php via fcgi
php.ini setting 'zlib.output_compression' is turned off
Test script:
---
error_reporting(E_ALL);
$zlib_oc = ini_get('zlib.output_compression');
if(empty($zlib_oc)) {
ob_start('ob_gzhandler');
}
echo 'test';
Expected result:
test
Actual result:
--
test with the error message attached that was mentioned above
--
Edit bug report at https://bugs.php.net/bug.php?id=62335&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62335&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62335&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62335&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62335&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62335&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62335&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62335&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62335&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62335&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62335&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62335&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62335&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62335&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62335&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62335&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62335&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62335&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62335&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62335&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62335&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62335&r=mysqlcfg
Bug #52376 [Com]: opendir() cannot open UNC paths in IIS7 using passthrough auth.
Edit report at https://bugs.php.net/bug.php?id=52376&edit=1
ID: 52376
Comment by: alexkyrlis at me dot com
Reported by:ryan at kisc dot edu dot np
Summary:opendir() cannot open UNC paths in IIS7 using
passthrough auth.
Status: Assigned
Type: Bug
Package:*Directory/Filesystem functions
Operating System: win64 - W2008R2
PHP Version:5.3.2
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Greetings,
I have the same problem, expect that, when testing this script:
I get no errors, PHP actually likes this path, no problem.
But, this same path is not accepted by Windows. Instead, the correct path that
Windows 2008 (and IIS) recognizes is:
\\node1\wwwroot\public\joomla
This is quite an annoying problem. Windows likes \ and php likes / in the path.
Any ideas?
Thanks
Alex
Previous Comments:
[2012-02-08 19:37:33] mike dot riendeau at gmail dot com
I fixed this in Win7 IIS7 Through the inetmgr.
WebSite->Authentication->Anonymous Authentication (edit on side panel)
I changed the Specific User (IUSR) to Application pool identity.
I am only using it for local development, so I'm not sure how this affects
security.
[2011-10-13 09:57:29] em at ducommun dot ch
I have exactly the same problem.
I have tried to map the share to a letter, exemple Z:/ same result.
This is not a permissions problem.
Please help.
Config: xampp running under w2k3r2 server, with php 5.3.5
Thanks!
[2011-08-05 15:14:58] marc dot seitz at ww-informatik dot de
Hi Guys,
we have exactly the same problem now.
We want to migrate to Windows Server 2008 R2 with IIS 7.5, FastCGI, PHP 5.3.6.
When I try to do a file_get_contents() or opendir() I
always will get the error:
Warning: fopen(): failed to open stream: Permission denied in
D:\inetpub\wwwroot\XXX.php on line 26
The Application-Pools of the IIS are running under a Domain-Account which has
access to the Network Share.
I don't know how to solve this problem.
Any ideas of you?
Thanks
Marc
[2011-01-13 04:24:50] mark at internode dot on dot net
Hi I am having the same problem with PHP 5.3.5 running under IIS 7.5, FastCGI,
Windows Server 2008 R2 where I am simply trying to access a file on another
server using a UNC path.
$uploadfile = "\.txt";
$fh = fopen($uploadfile, 'r') or die("Can't open file $uploadfile");
I have tried granting "everyone" full permissions for the share and the file
system but it still does not work.
This code works perfectly if the file is stored on the same server and is
accessed through a local path.
Other things I have tried inlcude:
- setting the defaultappool to use a specific user and granting that user
permissions on the share and file system
- using "network" as above
Any other ideas on this one?
[2010-07-20 04:42:43] ahar...@php.net
(Restoring status.)
As a fellow Chrome user, I feel your pain. :)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52376
--
Edit this bug report at https://bugs.php.net/bug.php?id=52376&edit=1
Bug #62236 [Opn->Fbk]: Hardcoded path /usr/local/bin/php
Edit report at https://bugs.php.net/bug.php?id=62236&edit=1 ID: 62236 Updated by: maar...@php.net Reported by:max dot antonoff at gmail dot com Summary:Hardcoded path /usr/local/bin/php -Status: Open +Status: Feedback Type: Bug Package:CGI/CLI related Operating System: Linux PHP Version:5.4.4RC2 Block user comment: N Private report: N New Comment: Max, could you please try/test the above hint? Previous Comments: [2012-06-11 12:59:53] Sjon at hortensius dot net /usr/bin/pear is a simple script that determines which PHP binary to use. It should be easy to debug this yourself, I think an incorrect $PHP_PEAR_PHP_BIN might cause this for example [2012-06-05 20:04:05] max dot antonoff at gmail dot com Description: max 23:58:24 php-src $ pear list-all exec: 28: /usr/local/bin/php: not found max 23:58:15 php-src $ php -v PHP 5.4.4-RC2 (cli) (built: Jun 5 2012 23:48:00) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies max 23:58:29 php-src $ which php ; which pear; php -i |grep configure /home/max/local/bin/php /home/max/local/bin/pear Configure Command => './configure' '--prefix=/home/max/local' '--enable-proxy' '--disable-cgi' '--with-mysqli' '--enable-fpm' '--with-fpm-user=max' '--with- fpm-group=max' '--with-config-file-path=/home/max/local/etc/php.ini' '--with- config-file-scan-dir=/home/max/local/etc/php.d' '--enable-sigchild' '--disable- ipv6' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--enable-bcmath' '-- with-bz2' '--with-curl' '--with-curlwrappers' '--enable-exif' '--enable-ftp' '-- with-gd' '--enable-gd-native-ttf' '--with-mhash' '--enable-mbstring' '--with- mcrypt' '--with-mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '-- enable-pcntl' '--with-pdo-mysql' '--enable-shmop' '--enable-soap' '--enable- sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable- wddx' '--with-xsl' '--enable-zip' '--enable-mysqlnd' '--with- pear=/home/max/local/PEAR' '--with-jpeg-dir' '--with-png-dir' '--enable-intl' Test script: --- max 23:58:24 php-src $ pear list-all Expected result: list of packages Actual result: -- exec: 28: /usr/local/bin/php: not found -- Edit this bug report at https://bugs.php.net/bug.php?id=62236&edit=1
Bug #62326 [Com]: date_diff() function returns false result
Edit report at https://bugs.php.net/bug.php?id=62326&edit=1
ID: 62326
Comment by: ploeger dot private at googlemail dot com
Reported by:ploeger dot private at googlemail dot com
Summary:date_diff() function returns false result
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows Server 2008 R2
PHP Version:5.3Git-2012-06-14 (snap)
Block user comment: N
Private report: N
New Comment:
Test script to show the behavior of the bug:
Test script:
---
diff($end)->format('%y Jahre %m Monate %d
Monatstage ( %a tage total )') ).PHP_EOL,
'gelisted : '.( in_array(strtolower($testZone), $possibleTimezones) ?
'Ja' : 'Nein' ).PHP_EOL,
'Alias : '.( strcasecmp($testZone, $cur->getName()) == 0 ? 'Nein' :
'Ja' ).PHP_EOL,
'Ist-TZ: '.( $cur->getName() ).PHP_EOL,
'start OfS : '.( ( $cur->getOffset($start) / 60 / 60 ) ).'
Stunden'.PHP_EOL,
'end OfS : '.( ( $cur->getOffset($end) / 60 / 60 ) ).'
Stunden'.PHP_EOL
));
}
echo join('--- '.PHP_EOL, $info);
Result:
Soll-TZ : europe/Berlin
Differenz : 0 Jahre 5 Monate 30 Monatstage ( 183 tage total )
gelisted : Ja
Alias : Nein
Ist-TZ: Europe/Berlin
start OfS : 2 Stunden
end OfS : 1 Stunden
---
Soll-TZ : GMT
Differenz : 0 Jahre 6 Monate 0 Monatstage ( 183 tage total )
gelisted : Nein
Alias : Ja
Ist-TZ: UTC
start OfS : 0 Stunden
end OfS : 0 Stunden
---
Soll-TZ : CET
Differenz : 0 Jahre 5 Monate 30 Monatstage ( 183 tage total )
gelisted : Nein
Alias : Ja
Ist-TZ: Europe/Berlin
start OfS : 2 Stunden
end OfS : 1 Stunden
---
Soll-TZ : UTC
Differenz : 0 Jahre 6 Monate 0 Monatstage ( 183 tage total )
gelisted : Ja
Alias : Nein
Ist-TZ: UTC
start OfS : 0 Stunden
end OfS : 0 Stunden
Previous Comments:
[2012-06-14 19:55:15] juergen78 at gmail dot com
My Hosters OS:
Linux alfa3025 2.6.32-bpo.5-amd64 #1 SMP Wed Jul 20 09:10:04 UTC 2011 x86_64
Code:
-
date_default_timezone_set("Europe/Berlin");
$start_timestamp= date_create('2012-06-01');
$end_timestamp = date_create('2012-12-01');
$difference = date_diff($start_timestamp, $end_timestamp);
$difference = $difference->format('%M');
echo $difference;
Output:
05
[2012-06-14 19:13:58] ploeger dot private at googlemail dot com
I could reproduce the bug on WinXP Pro SP3, Win Server 2008 R2 and Win7 Pro.
Default Timezone: Europe/Berlin
Workaround with correct result:
date_default_timezone_set("UTC");
$start_timestamp= date_create('2012-06-01');
$end_timestamp = date_create('2012-12-01');
$difference = date_diff($start_timestamp, $end_timestamp);
var_dump($difference); //6 months
Could you reproduce the bug with:
date.timezone = "Europe/Berlin"
in php.ini on linux?
[2012-06-14 19:00:49] ras...@php.net
That output 06 on Linux
[2012-06-14 18:52:28] ploeger dot private at googlemail dot com
Description:
The source code will return 05 instead of 06.
If you change the day to 02 instead of 01 in start_timestamp and end_timestamp
everything seems to work correct.
Debug:
print_r($start_timestamp);
Result: DateTime Object ( [date] => 2012-06-01 00:00:00 [timezone_type] => 3
[timezone] => Europe/Berlin )
print_r($end_timestamp);
Result: DateTime Object ( [date] => 2012-12-01 00:00:00 [timezone_type] => 3
[timezone] => Europe/Berlin )
Test script:
---
$start_timestamp= date_create('2012-06-01');
$end_timestamp = date_create('2012-12-01');
$difference = date_diff($start_timestamp, $end_timestamp);
$difference = $difference->format('%M');
Expected result:
06
Actual result:
--
05
--
Edit this bug report at https://bugs.php.net/bug.php?id=62326&edit=1
Bug #62330 [Com]: PHP confuse "__callStatic" with "__call"
Edit report at https://bugs.php.net/bug.php?id=62330&edit=1 ID: 62330 Comment by: Sjon at hortensius dot net Reported by:magike dot net at gmail dot com Summary:PHP confuse "__callStatic" with "__call" Status: Open Type: Bug Package:Scripting Engine problem Operating System: Ubuntu Server 12.04 PHP Version:5.3.14 Block user comment: N Private report: N New Comment: I actually found a related bug, I filed it here: https://bugs.php.net/bug.php?id=62333 PS. there is a small typo in your script, your last call to ->text() should have gone to ->test() Previous Comments: [2012-06-15 10:46:13] Sjon at hortensius dot net This is actually a feature: when you use CLASSNAME:: while extending that class, it mimics parent::, but to a specific class (so you can skip one parent) You should instead use forward_static_call for this [2012-06-15 02:40:29] magike dot net at gmail dot com Description: I find PHP will call "__call" instead of "__callStatic" when I'm calling a non- exists static method from the class (Class A) which is the parent of current class (Class B). And if the class (Class C) is not the child of that class (Class A), the result will be correct. Test script: --- test(); $c = new C(); $c->text(); Expected result: YES YES YES Actual result: -- YES NO YES -- Edit this bug report at https://bugs.php.net/bug.php?id=62330&edit=1
[PHP-BUG] Bug #62333 [NEW]: Cannot statically call method to parent class
From: Sjon at hortensius dot net Operating system: PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Bug Bug description:Cannot statically call method to parent class Description: All static calls to a class-parent end up being non-static Inconsistency clearly proven: http://3v4l.org/Mkn0L http://3v4l.org/1L3Wk (same, but without __call) Test script: --- See http://3v4l.org/Mkn0L test(); echo " = C =\n"; $c = new C(); $c->test(); Expected result: Static = B = Not static Not static Not static = C = Static Static Static Actual result: -- Static = B = Not static Not static Not static = C = Static Static Static -- Edit bug report at https://bugs.php.net/bug.php?id=62333&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62333&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62333&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62333&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62333&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62333&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62333&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62333&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62333&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62333&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62333&r=support Expected behavior: https://bugs.php.net/fix.php?id=62333&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62333&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62333&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62333&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62333&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62333&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62333&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62333&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62333&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62333&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62333&r=mysqlcfg
Bug #62330 [Com]: PHP confuse "__callStatic" with "__call"
Edit report at https://bugs.php.net/bug.php?id=62330&edit=1 ID: 62330 Comment by: Sjon at hortensius dot net Reported by:magike dot net at gmail dot com Summary:PHP confuse "__callStatic" with "__call" Status: Open Type: Bug Package:Scripting Engine problem Operating System: Ubuntu Server 12.04 PHP Version:5.3.14 Block user comment: N Private report: N New Comment: This is actually a feature: when you use CLASSNAME:: while extending that class, it mimics parent::, but to a specific class (so you can skip one parent) You should instead use forward_static_call for this Previous Comments: [2012-06-15 02:40:29] magike dot net at gmail dot com Description: I find PHP will call "__call" instead of "__callStatic" when I'm calling a non- exists static method from the class (Class A) which is the parent of current class (Class B). And if the class (Class C) is not the child of that class (Class A), the result will be correct. Test script: --- test(); $c = new C(); $c->text(); Expected result: YES YES YES Actual result: -- YES NO YES -- Edit this bug report at https://bugs.php.net/bug.php?id=62330&edit=1
Bug #62313 [Opn]: Zend\tests\errmsg_021.phpt fails
Edit report at https://bugs.php.net/bug.php?id=62313&edit=1 ID: 62313 Updated by: paj...@php.net Reported by:a...@php.net Summary:Zend\tests\errmsg_021.phpt fails Status: Open Type: Bug Package:Reproducible crash Operating System: windows PHP Version:5.4Git-2012-06-13 (snap) Block user comment: N Private report: N New Comment: Disable optimization for the new handler is going to kill many perf improvements in 5.4+. I am sure the issue occurs later on, inside the error management or the ini fetching code. But I cannot let this patch in as it is now, disabling optimization for new is no-no :) Previous Comments: [2012-06-15 09:39:27] a...@php.net The fail seems to be caused only in builds using PGO, the patch disables it for the relevant place. [2012-06-15 09:38:28] a...@php.net The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339753108 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339753108 [2012-06-13 11:46:49] a...@php.net Description: Test diff: 002- Done What is really going on behind the scenes is a crash. The strange thing here is - it fails only on the snapshots, running the test on a self compiled binary passes. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=62313&edit=1
Bug #62313 [Com]: Zend\tests\errmsg_021.phpt fails
Edit report at https://bugs.php.net/bug.php?id=62313&edit=1 ID: 62313 Comment by: a...@php.net Reported by:a...@php.net Summary:Zend\tests\errmsg_021.phpt fails Status: Open Type: Bug Package:Reproducible crash Operating System: windows PHP Version:5.4Git-2012-06-13 (snap) Block user comment: N Private report: N New Comment: The fail seems to be caused only in builds using PGO, the patch disables it for the relevant place. Previous Comments: [2012-06-15 09:38:28] a...@php.net The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339753108 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339753108 [2012-06-13 11:46:49] a...@php.net Description: Test diff: 002- Done What is really going on behind the scenes is a crash. The strange thing here is - it fails only on the snapshots, running the test on a self compiled binary passes. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=62313&edit=1
Bug #62313 [PATCH]: Zend\tests\errmsg_021.phpt fails
Edit report at https://bugs.php.net/bug.php?id=62313&edit=1 ID: 62313 Patch added by: a...@php.net Reported by:a...@php.net Summary:Zend\tests\errmsg_021.phpt fails Status: Open Type: Bug Package:Reproducible crash Operating System: windows PHP Version:5.4Git-2012-06-13 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 62313.patch Revision: 1339753108 URL: https://bugs.php.net/patch-display.php?bug=62313&patch=62313.patch&revision=1339753108 Previous Comments: [2012-06-13 11:46:49] a...@php.net Description: Test diff: 002- Done What is really going on behind the scenes is a crash. The strange thing here is - it fails only on the snapshots, running the test on a self compiled binary passes. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=62313&edit=1
Bug #62260 [Opn->Csd]: XPath does not search correctly in nodes with text and other nodes
Edit report at https://bugs.php.net/bug.php?id=62260&edit=1
ID: 62260
User updated by:yajo dot sk8 at gmail dot com
Reported by:yajo dot sk8 at gmail dot com
Summary:XPath does not search correctly in nodes with text
and other nodes
-Status: Open
+Status: Closed
Type: Bug
Package:*XML functions
Operating System: Linux
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
Salathe, thanks for the point, you are right.
Replacing the xquery by '//text()[contains(., "world")]/..' works perfectly.
Previous Comments:
[2012-06-08 08:29:46] sala...@php.net
I may be wrong, but my understanding is as follows.
text() returns a list of node [1], whereas contains() expects two string
arguments [2]. Because of this the list of
text nodes is converted to a string, as with string():
"A node-set is converted to a string by returning the string-value of the node
in the node-set that is first in
document order. If the node-set is empty, an empty string is returned." [3]
[1] http://www.w3.org/TR/xpath/#path-abbrev
[2] http://www.w3.org/TR/xpath/#function-contains
[3] http://www.w3.org/TR/xpath/#function-string
[2012-06-08 07:34:19] yajo dot sk8 at gmail dot com
Description:
When a node has inner nodes and you want to search into its text value, only
the first text node is selected.
This is wrong because, as http://www.w3.org/TR/xpath/#path-abbrev says:
> text() selects all text node children of the context node
Test script:
---
$xml = <<
Hello
world
world
END;
$doc = DOMDocument::loadXML($xml);
$xpath = new DOMXPath($doc);
foreach ($xpath->query('//*[contains(text(), "world")]') as $node)
echo $node->nodeName . PHP_EOL;
Expected result:
first
second
Actual result:
--
second
--
Edit this bug report at https://bugs.php.net/bug.php?id=62260&edit=1
Bug #62331 [Opn]: DateTime::add() produces inconsistent resultst
Edit report at https://bugs.php.net/bug.php?id=62331&edit=1
ID: 62331
Updated by: sala...@php.net
Reported by:ruesche at fka dot de
Summary:DateTime::add() produces inconsistent resultst
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows, Linux
PHP Version:Irrelevant
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This looks like a side-effect of the changes made against bug #55253.
Previous Comments:
[2012-06-15 08:48:06] ruesche at fka dot de
typo fixed.
[2012-06-15 08:46:43] ruesche at fka dot de
Description:
When you use a timezone with daylight saving time (like Europe/Berlin) and the
date of the system running the PHP script is in this daylight saving time (like
2012-06-15), DateTime::add() will produce results that are off by 1 hour.
When the date on the local machine is not in the daylight saving time, the same
computation will yield the expceted results.
This bug also only appears, when the DateTime instance was created using a
timestamp, so a workaround would be the following: Instead of
$date = new DateTime(gmmktime(0, 0, 0, 1, 1, 2012));
use
$date = new DateTime('2012-01-01');
The script was tested with the following systems, all having the same problem:
- Windows XP, PHP 5.3.10
- Windows XP, PHP 5.3.13
- Windows 7, PHP 5.3.10
- Arch Linux (x86_64), PHP 5.4.3
- Debian Squeeze, PHP 5.3.10
Test script:
---
format('Y-m-d H:i:s')."\n";
$date->add($oneMonth);
echo $date->format('Y-m-d H:i:s')."\n";
Expected result:
2012-01-01 00:00:00
2012-02-01 00:00:00
Actual result:
--
2012-01-01 00:00:00
2012-02-01 01:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62331&edit=1
Bug #62331 [Opn]: DateTime::add() produces inconsistent resultst
Edit report at https://bugs.php.net/bug.php?id=62331&edit=1
ID: 62331
User updated by:ruesche at fka dot de
Reported by:ruesche at fka dot de
-Summary:DateTime::add() produces inconsisten results
+Summary:DateTime::add() produces inconsistent resultst
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows, Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
typo fixed.
Previous Comments:
[2012-06-15 08:46:43] ruesche at fka dot de
Description:
When you use a timezone with daylight saving time (like Europe/Berlin) and the
date of the system running the PHP script is in this daylight saving time (like
2012-06-15), DateTime::add() will produce results that are off by 1 hour.
When the date on the local machine is not in the daylight saving time, the same
computation will yield the expceted results.
This bug also only appears, when the DateTime instance was created using a
timestamp, so a workaround would be the following: Instead of
$date = new DateTime(gmmktime(0, 0, 0, 1, 1, 2012));
use
$date = new DateTime('2012-01-01');
The script was tested with the following systems, all having the same problem:
- Windows XP, PHP 5.3.10
- Windows XP, PHP 5.3.13
- Windows 7, PHP 5.3.10
- Arch Linux (x86_64), PHP 5.4.3
- Debian Squeeze, PHP 5.3.10
Test script:
---
format('Y-m-d H:i:s')."\n";
$date->add($oneMonth);
echo $date->format('Y-m-d H:i:s')."\n";
Expected result:
2012-01-01 00:00:00
2012-02-01 00:00:00
Actual result:
--
2012-01-01 00:00:00
2012-02-01 01:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62331&edit=1
[PHP-BUG] Bug #62331 [NEW]: DateTime::add() produces inconsisten results
From: ruesche at fka dot de
Operating system: Windows, Linux
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::add() produces inconsisten results
Description:
When you use a timezone with daylight saving time (like Europe/Berlin) and
the date of the system running the PHP script is in this daylight saving
time (like 2012-06-15), DateTime::add() will produce results that are off
by 1 hour.
When the date on the local machine is not in the daylight saving time, the
same computation will yield the expceted results.
This bug also only appears, when the DateTime instance was created using a
timestamp, so a workaround would be the following: Instead of
$date = new DateTime(gmmktime(0, 0, 0, 1, 1, 2012));
use
$date = new DateTime('2012-01-01');
The script was tested with the following systems, all having the same
problem:
- Windows XP, PHP 5.3.10
- Windows XP, PHP 5.3.13
- Windows 7, PHP 5.3.10
- Arch Linux (x86_64), PHP 5.4.3
- Debian Squeeze, PHP 5.3.10
Test script:
---
format('Y-m-d H:i:s')."\n";
$date->add($oneMonth);
echo $date->format('Y-m-d H:i:s')."\n";
Expected result:
2012-01-01 00:00:00
2012-02-01 00:00:00
Actual result:
--
2012-01-01 00:00:00
2012-02-01 01:00:00
--
Edit bug report at https://bugs.php.net/bug.php?id=62331&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62331&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62331&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62331&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62331&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62331&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62331&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62331&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62331&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62331&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62331&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62331&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62331&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62331&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62331&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62331&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62331&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62331&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62331&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62331&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62331&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62331&r=mysqlcfg
Req #42516 [Com]: __FILE__ resolves symlinks
Edit report at https://bugs.php.net/bug.php?id=42516&edit=1 ID: 42516 Comment by: daniele dot segato at gmail dot com Reported by:michael at zedeler dot dk Summary:__FILE__ resolves symlinks Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:4.4.7 Block user comment: N Private report: N New Comment: This bug was open since 2007 would you mind assigning it to someone for fixing or discuss why you are leaving it open? maybe someone out there can help you thank you Previous Comments: [2012-04-06 17:28:55] bj...@php.net I don't know why this was assigned to me [2011-08-20 09:56:33] clicky at erebot dot net Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a website. It's completely useless in case you're working from a terminal (eg. some unit tests run through PHPUnit). +1 on having this behaviour changed (maybe as a second magic constant as other proposed, so as not to break backward compatibility for __FILE__). [2011-07-20 05:23:46] mpok at xs4all dot nl @Tyra3l: the problem most people (including myself) are having is that $_SERVER["SCRIPT_FILENAME"] contains the path to the file that was called, not the path to the file that is actually processed. This means you can't use $_SERVER["SCRIPT_FILENAME"] as a replacement for __FILE__; in fact there is no way to get a non-resolved path to the current script. Example: Website calls [DOCUMENT_ROOT]/index.php Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php Both files include [DOCUMENT_ROOT]/lib/config/startup.php Now the startup.php script has to set path variables/constants to use throughout the framework. If you use __FILE__ for this it will return the path to the settings.php script, regardless of whether it was included/called from the website (index.php) or the cronjob (maintenance.php). This allows you to reliably set paths relative to the location of settings.php. However if you symlink the /lib/ directory __FILE__ will resolve the symlinked path and thus break for setting the framework paths relative to the website. Using $_SERVER["SCRIPT_FILENAME"] in startup.php will result in different paths depending on which file was called. When called from the website it returns " [DOCUMENT_ROOT]/index.php", when called from the cronjob it returns " [DOCUMENT_ROOT]/lib/cron/maintenance.php". This means that if you want to make sure you get a reliable path to the lib inside the website you'd have to write a bunch of additional code with semi-intelligent matching in order to find a specific path, if at all possible. Another option is to set the base path seperately in each file that is an entry point for the framework so that those files define their existence relative to the lib dir. This does create more dependencies though. All in all it would be far better if there was an option in the php.ini to disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to resolve symlinks I'd use realpath() anyway. [2011-04-13 09:32:46] tyra3l at gmail dot com $_SERVER["SCRIPT_FILENAME"] can be used for getting the non-resolved path, and the documentation at http://php.net/manual/en/language.constants.predefined.php now contains info about __FILE__ is resolved to absolute path with resolved symlinks. so I think that this could be closed. Tyrael [2009-08-17 12:57:30] michael at zedeler dot dk Fixed subject. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=42516 -- Edit this bug report at https://bugs.php.net/bug.php?id=42516&edit=1
