Bug #61568 [Csd]: PHP crashes while including classes without any error message or log
Edit report at https://bugs.php.net/bug.php?id=61568&edit=1 ID: 61568 Updated by: ahar...@php.net Reported by:login dot naitsirch at arcor dot de Summary:PHP crashes while including classes without any error message or log Status: Closed Type: Bug Package:Reproducible crash Operating System: Win 7 (x64) PHP Version:5.3.10 Assigned To:aharvey Block user comment: N Private report: N New Comment: Damned auto-assign. Previous Comments: [2012-08-06 06:01:53] ahar...@php.net Fixed, per OP. [2012-05-24 09:23:21] login dot naitsirch at arcor dot de In PHP 5.3.13 this problem seem to be fixed. [2012-04-04 13:30:50] login dot naitsirch at arcor dot de Hi. display_errors is On and PHP crashes also if I only include the InvoiceProcessor.php. The point is that the script does not only exit because of any error. It really crashes. You can see a screenshot here http://www.abload.de/img/php-erroryvk88.png I found out that a Windows event report is created. Application Error Name der fehlerhaften Anwendung: php.exe, Version: 5.3.10.0, Zeitstempel: 0x4f2ae50c Name des fehlerhaften Moduls: php5ts.dll, Version: 5.3.10.0, Zeitstempel: 0x4f2ae5d1 Ausnahmecode: 0xc005 Fehleroffset: 0x000a3b02 ID des fehlerhaften Prozesses: 0x1b70 Startzeit der fehlerhaften Anwendung: 0x01cd1264a473718d Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\PHP\php.exe Pfad des fehlerhaften Moduls: C:\Program Files (x86)\PHP\php5ts.dll Berichtskennung: e2bf8482-7e57-11e1-926f-e06995696037 Sorry, it is in German because I have the German Win7 edition [2012-04-04 10:09:52] reeze dot xia at gmail dot com Hi, naitsirch: I did't reproduce it in PHP5.3. I've notice that, those two files really do nothing but declare classes. "Product.php would Fatal because of "Leonex_Core_Model_Abstract" not found. It's reasonable. but the anther file inclusion do nothing is expected. but if you turn display_errors to Off. it will output nothing. Please check your ini config. [2012-03-30 15:30:04] login dot naitsirch at arcor dot de Description: Hi, I have a strange problem with two PHP scripts. If I include them in another file without doing anything else PHP will crash without any error message. It doesn't matter if you execute it with CLI or via web server. But if I change or remove any char even in the comments the script works again. Maybe there is any special char in the script which result in a PHP crash during parsing. This problem occurs in PHP 5.3.9 and 5.3.10 on Windows. I have not tested it on Linux. Test script: --- I have uploaded a ZIP archive which contains three files: test.php, Product.php and InvoiceProcessor.php You have just to execute or call the 'test.php' (via CLI or web server). Product.php and InvoiceProcessor.php contains both one class. Link to download page: http://www.filehosting.org/file/details/326139/test.zip -- Edit this bug report at https://bugs.php.net/bug.php?id=61568&edit=1
Bug #61568 [Opn->Csd]: PHP crashes while including classes without any error message or log
Edit report at https://bugs.php.net/bug.php?id=61568&edit=1 ID: 61568 Updated by: ahar...@php.net Reported by:login dot naitsirch at arcor dot de Summary:PHP crashes while including classes without any error message or log -Status: Open +Status: Closed Type: Bug Package:Reproducible crash Operating System: Win 7 (x64) PHP Version:5.3.10 -Assigned To: +Assigned To:aharvey Block user comment: N Private report: N New Comment: Fixed, per OP. Previous Comments: [2012-05-24 09:23:21] login dot naitsirch at arcor dot de In PHP 5.3.13 this problem seem to be fixed. [2012-04-04 13:30:50] login dot naitsirch at arcor dot de Hi. display_errors is On and PHP crashes also if I only include the InvoiceProcessor.php. The point is that the script does not only exit because of any error. It really crashes. You can see a screenshot here http://www.abload.de/img/php-erroryvk88.png I found out that a Windows event report is created. Application Error Name der fehlerhaften Anwendung: php.exe, Version: 5.3.10.0, Zeitstempel: 0x4f2ae50c Name des fehlerhaften Moduls: php5ts.dll, Version: 5.3.10.0, Zeitstempel: 0x4f2ae5d1 Ausnahmecode: 0xc005 Fehleroffset: 0x000a3b02 ID des fehlerhaften Prozesses: 0x1b70 Startzeit der fehlerhaften Anwendung: 0x01cd1264a473718d Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\PHP\php.exe Pfad des fehlerhaften Moduls: C:\Program Files (x86)\PHP\php5ts.dll Berichtskennung: e2bf8482-7e57-11e1-926f-e06995696037 Sorry, it is in German because I have the German Win7 edition [2012-04-04 10:09:52] reeze dot xia at gmail dot com Hi, naitsirch: I did't reproduce it in PHP5.3. I've notice that, those two files really do nothing but declare classes. "Product.php would Fatal because of "Leonex_Core_Model_Abstract" not found. It's reasonable. but the anther file inclusion do nothing is expected. but if you turn display_errors to Off. it will output nothing. Please check your ini config. [2012-03-30 15:30:04] login dot naitsirch at arcor dot de Description: Hi, I have a strange problem with two PHP scripts. If I include them in another file without doing anything else PHP will crash without any error message. It doesn't matter if you execute it with CLI or via web server. But if I change or remove any char even in the comments the script works again. Maybe there is any special char in the script which result in a PHP crash during parsing. This problem occurs in PHP 5.3.9 and 5.3.10 on Windows. I have not tested it on Linux. Test script: --- I have uploaded a ZIP archive which contains three files: test.php, Product.php and InvoiceProcessor.php You have just to execute or call the 'test.php' (via CLI or web server). Product.php and InvoiceProcessor.php contains both one class. Link to download page: http://www.filehosting.org/file/details/326139/test.zip -- Edit this bug report at https://bugs.php.net/bug.php?id=61568&edit=1
Bug #55364 [Com]: DirectoryIterator fails to list VirtualBox shared folder contents
Edit report at https://bugs.php.net/bug.php?id=55364&edit=1 ID: 55364 Comment by: nogod dot mail at gmail dot com Reported by:bob at synapsestudios dot com Summary:DirectoryIterator fails to list VirtualBox shared folder contents Status: Closed Type: Bug Package:SPL related Operating System: Ubuntu Server "natty" 32-bit PHP Version:5.3.6 Block user comment: N Private report: N New Comment: This issue can be reproduced with sshfs mounted folder. Previous Comments: [2011-08-16 16:24:57] bob at synapsestudios dot com This has been fixed by upgraded the VBox and Guest Additions as suggested (Thanks Paul!). Just a note, that I was on Vbox 4.0 and was not informed of the newer 4.1 version available. I had to manually go to the VBox site to download the new version. [2011-08-16 08:07:55] vbox-dev at paul-mitchell dot me dot uk Please upgrade to VirtualBox 4.1.2 + Guest Additions (released 2011-08-15) which has a fix for this issue. [2011-08-04 18:15:09] bob at synapsestudios dot com Description: I recently updated to 5.3.6 on a VirtualBox VM that uses a shared directory from my Windows 7 (64-bit) machine for project files. I've since determined that DirectoryIterator fails to locate any files in the shared directory. Upon further inspection, it works fine for any other directory on the VM. I've also confirmed that the same issue does not happen when going from a Linux machine to the VM leading me to believe that this is NTFS-related. The last known working version was 5.3.3. Version 5.3.5 had the same issues as the current version and I did not test on 5.3.4. Googling found another person with the same problem: http://www.searbe.co.uk/phpunit-and-virtualbox-uncaught-exception-php Test script: --- DirectoryIterator Test on VirtualBox Shared Folders Passing getFilename()); } ?> Failing getFilename()); } Expected result: List all of the files in the shared folder directory Actual result: -- No files are found -- Edit this bug report at https://bugs.php.net/bug.php?id=55364&edit=1
Bug #51363 [Csd]: Fatal error raised by var_export() not caught by error handler
Edit report at https://bugs.php.net/bug.php?id=51363&edit=1
ID: 51363
Updated by: s...@php.net
Reported by:daan at react dot com
Summary:Fatal error raised by var_export() not caught by
error handler
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Debian Etch
PHP Version:5.2.13
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Unfortunately, no good way to var_export recursive structures yet. You can use
serialize() for that.
Previous Comments:
[2012-08-06 04:00:50] s...@php.net
fixed in 5.4 & trunk - var_export no longer produces fatal error but produces
warning instead on recursion.
[2012-08-06 04:00:06] s...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2010-11-05 03:32:42] yohgaki at ohgaki dot net
I was biten by this bug recently.
Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not
have protection against recursive arrays.
Therefore, zend_error() is raised in Zend Engine with E_ERROR.
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible
to catch exception or error by user error handler.
Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and
raize E_NOTICE error for recursive dependency.
Since php_var_export() allows only one zval, export recursive dependency
correctly by using '&'.
This bug is applicable to 5.2/5.3/trunk.
[2010-07-02 11:12:20] daan at react dot com
No I do not expect it to go on infinitely - the bug is that the php error
caused by var_export() in this case is not caught by the error handler, when it
should be.
[2010-04-22 22:37:22] whatrevolution at yahoo dot com
I am curious if the bug OP expects the var_export() output to never end...
ever? I do, because it is a recursive reference, so I'm puzzled that this is
considered a bug.
However, perhaps the solution would be to not throw a fatal error, but throw a
notice or warning and/or provide some way of telling var_export() how deep to
print.
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in
/var/www/php_bugs/var_export_recursion_test.php on line 36
Call Stack
# TimeMemory FunctionLocation
1 0.0004 108776 {main}( ) ../var_export_recursion_test.php:0
2 0.0004 109968 var_export ( ) ../var_export_recursion_test.php:36
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
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=51363
--
Edit this bug report at https://bugs.php.net/bug.php?id=51363&edit=1
Bug #51363 [Csd]: Fatal error raised by var_export() not caught by error handler
Edit report at https://bugs.php.net/bug.php?id=51363&edit=1
ID: 51363
Updated by: s...@php.net
Reported by:daan at react dot com
Summary:Fatal error raised by var_export() not caught by
error handler
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Debian Etch
PHP Version:5.2.13
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
fixed in 5.4 & trunk - var_export no longer produces fatal error but produces
warning instead on recursion.
Previous Comments:
[2012-08-06 04:00:06] s...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2010-11-05 03:32:42] yohgaki at ohgaki dot net
I was biten by this bug recently.
Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not
have protection against recursive arrays.
Therefore, zend_error() is raised in Zend Engine with E_ERROR.
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible
to catch exception or error by user error handler.
Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and
raize E_NOTICE error for recursive dependency.
Since php_var_export() allows only one zval, export recursive dependency
correctly by using '&'.
This bug is applicable to 5.2/5.3/trunk.
[2010-07-02 11:12:20] daan at react dot com
No I do not expect it to go on infinitely - the bug is that the php error
caused by var_export() in this case is not caught by the error handler, when it
should be.
[2010-04-22 22:37:22] whatrevolution at yahoo dot com
I am curious if the bug OP expects the var_export() output to never end...
ever? I do, because it is a recursive reference, so I'm puzzled that this is
considered a bug.
However, perhaps the solution would be to not throw a fatal error, but throw a
notice or warning and/or provide some way of telling var_export() how deep to
print.
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in
/var/www/php_bugs/var_export_recursion_test.php on line 36
Call Stack
# TimeMemory FunctionLocation
1 0.0004 108776 {main}( ) ../var_export_recursion_test.php:0
2 0.0004 109968 var_export ( ) ../var_export_recursion_test.php:36
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
[2010-03-23 12:58:59] daan at react dot com
Description:
When a fatal error is raised by var_export() when trying to export a resursive
array, it is not caught by a user php error handler.
Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);
/* Don't execute PHP internal error handler */
return true;
}
set_error_handler("myErrorHandler");
$recursive = array();
$recursive[] = &$recursive;
var_export($recursive);
Expected result:
The var_dumped variables
Actual result:
--
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
Fatal error: Nesting level too deep - recursive dependency? in test.php on line
x
--
Edit this bug report at https://bugs.php.net/bug.php?id=51363&edit=1
Bug #51363 [Asn->Csd]: Fatal error raised by var_export() not caught by error handler
Edit report at https://bugs.php.net/bug.php?id=51363&edit=1
ID: 51363
Updated by: s...@php.net
Reported by:daan at react dot com
Summary:Fatal error raised by var_export() not caught by
error handler
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Debian Etch
PHP Version:5.2.13
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-11-05 03:32:42] yohgaki at ohgaki dot net
I was biten by this bug recently.
Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not
have protection against recursive arrays.
Therefore, zend_error() is raised in Zend Engine with E_ERROR.
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible
to catch exception or error by user error handler.
Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and
raize E_NOTICE error for recursive dependency.
Since php_var_export() allows only one zval, export recursive dependency
correctly by using '&'.
This bug is applicable to 5.2/5.3/trunk.
[2010-07-02 11:12:20] daan at react dot com
No I do not expect it to go on infinitely - the bug is that the php error
caused by var_export() in this case is not caught by the error handler, when it
should be.
[2010-04-22 22:37:22] whatrevolution at yahoo dot com
I am curious if the bug OP expects the var_export() output to never end...
ever? I do, because it is a recursive reference, so I'm puzzled that this is
considered a bug.
However, perhaps the solution would be to not throw a fatal error, but throw a
notice or warning and/or provide some way of telling var_export() how deep to
print.
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in
/var/www/php_bugs/var_export_recursion_test.php on line 36
Call Stack
# TimeMemory FunctionLocation
1 0.0004 108776 {main}( ) ../var_export_recursion_test.php:0
2 0.0004 109968 var_export ( ) ../var_export_recursion_test.php:36
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
[2010-03-23 12:58:59] daan at react dot com
Description:
When a fatal error is raised by var_export() when trying to export a resursive
array, it is not caught by a user php error handler.
Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);
/* Don't execute PHP internal error handler */
return true;
}
set_error_handler("myErrorHandler");
$recursive = array();
$recursive[] = &$recursive;
var_export($recursive);
Expected result:
The var_dumped variables
Actual result:
--
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
Fatal error: Nesting level too deep - recursive dependency? in test.php on line
x
--
Edit this bug report at https://bugs.php.net/bug.php?id=51363&edit=1
Bug #62460 [Asn->Csd]: php binaries installed as binary.dSYM
Edit report at https://bugs.php.net/bug.php?id=62460&edit=1 ID: 62460 Updated by: s...@php.net Reported by:phpbugs at adam dot gs Summary:php binaries installed as binary.dSYM -Status: Assigned +Status: Closed Type: Bug Package:*Compile Issues Operating System: OSX 10.8 PHP Version:5.3.14 Assigned To:johannes Block user comment: N Private report: N New Comment: 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-08-06 03:28:09] s...@php.net Automatic comment on behalf of reeze@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=07ee764e5709dc8d9f26382d8e7438696f5bb834 Log: Fixed bug #62460 (php binaries installed as binary.dSYM) [2012-07-20 02:55:21] reeze dot xia at gmail dot com Hi, The new released PHP-5.3.15 still have this bug. you could use the distributed tar package to reproduce. using google to search php.dSYM there are a lot of result about it. Thanks [2012-07-19 06:45:26] larue...@php.net johannes, could you please look at this? thanks [2012-07-19 06:32:38] reeze dot xia at gmail dot com Hi, OSX 10.9 haven't exist at all, although *nix os didn't have any extension for executable. but I'm ok with *darwin* match too. [2012-07-18 17:56:00] phpbugs at adam dot gs Perhaps we should just reduce that check to *darwin*? If not its just as likely to break again on 10.9, the *darwin* test seems much simpler in any event. Interestingly I saw that line and though, "that's not it because it works on 10.7 for me" I just retested and it DOES break on 10.7. 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=62460 -- Edit this bug report at https://bugs.php.net/bug.php?id=62460&edit=1
Bug #61642 [Opn->Csd]: modify("+5 weekdays") returns Sunday
Edit report at https://bugs.php.net/bug.php?id=61642&edit=1
ID: 61642
Updated by: s...@php.net
Reported by:jeff at nd4c dot com
Summary:modify("+5 weekdays") returns Sunday
-Status: Open
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: Fedora 14 and Windows 7
PHP Version:Irrelevant
-Assigned To:
+Assigned To:stas
Block user comment: N
Private report: N
New Comment:
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
fixed in master
Previous Comments:
[2012-08-06 02:25:51] s...@php.net
Automatic comment on behalf of johnnysp...@gmail.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=a6a7787cf25af0cf5b5672b677e20d9d40963137
Log: Fix #61642: modify("+5 weekdays") returns Sunday
[2012-04-11 16:11:26] jeff at nd4c dot com
The documentation is at:
http://www.php.net/manual/en/datetime.formats.relative.php
That page is linked to from:
http://www.php.net/manual/en/datetime.formats.php
Which is linked to from:
http://www.php.net/manual/en/datetime.modify.php
[2012-04-11 15:56:41] zhanglijiu at gmail dot com
I check the php manual, there is no weekdays parameter for modify. So you have
to
use modify(+ n day) or modify(+ n week).
[2012-04-05 18:01:12] jeff at nd4c dot com
Description:
Tested on Windows 7:
Apache/2.2.16 (Win32) PHP/5.3.5
Tested on Fedora 14:
Fedora release 14 (Laughlin) Linux 2.6.35.4-rscloud x86_64
php.x86_64 5.3.8-3.fc14
These are the latest stable versions I can find for these two systems.
(Especially since V6 binaries are no longer available for Windows.)
The Linux system is a live server using a framework that has not been tested
with any later versions than 5.3.8
When modifying a DateTime instance with "+5 weekdays" it will return a date for
a Sunday and not a weekday.
Running the Test script you note that the section for "5" returns Sunday. All
the other numbers are correct. Note the pattern for skipping the weekends is
always for Friday, Saturday and Sunday. However for "+5" weekends should be
skipped for Saturday, Sunday and Monday, which is different than for any other
number.
Test script:
---
$days = array(1,2,3,4,5,6,7,8,);
$dates =
array('2012-03-29','2012-03-30','2012-03-31','2012-04-01','2012-04-02','2012-04-03','2012-04-04','2012-04-05',);
foreach ($days as $businessdays)
{
foreach ($dates as $startdate)
{
$start = new DateTime($startdate);
$date = new DateTime($startdate);
echo ''.$businessdays.' : '.$date->format('l').' :
'.$date->format('Y-m-d');
$date->modify("+{$businessdays} weekdays");
echo ' : '.$date->format('Y-m-d').' : '.$date->format('l');
}
echo '';
}
Expected result:
...
5 : Thursday : 2012-03-29 : 2012-04-05 : Thursday
5 : Friday : 2012-03-30 : 2012-04-06 : Friday
5 : Saturday : 2012-03-31 : 2012-04-09 : Monday
5 : Sunday : 2012-04-01 : 2012-04-09 : Monday
5 : Monday : 2012-04-02 : 2012-04-09 : Monday
5 : Tuesday : 2012-04-03 : 2012-04-10 : Tuesday
5 : Wednesday : 2012-04-04 : 2012-04-11 : Wednesday
5 : Thursday : 2012-04-05 : 2012-04-12 : Thursday
...
Actual result:
--
...
5 : Thursday : 2012-03-29 : 2012-04-05 : Thursday
5 : Friday : 2012-03-30 : 2012-04-08 : Sunday
5 : Saturday : 2012-03-31 : 2012-04-08 : Sunday
5 : Sunday : 2012-04-01 : 2012-04-08 : Sunday
5 : Monday : 2012-04-02 : 2012-04-09 : Monday
5 : Tuesday : 2012-04-03 : 2012-04-10 : Tuesday
5 : Wednesday : 2012-04-04 : 2012-04-11 : Wednesday
5 : Thursday : 2012-04-05 : 2012-04-12 : Thursday
...
--
Edit this bug report at https://bugs.php.net/bug.php?id=61642&edit=1
Req #62422 [Opn->Wfx]: Function that always produces legal JSON
Edit report at https://bugs.php.net/bug.php?id=62422&edit=1
ID: 62422
Updated by: ahar...@php.net
Reported by:arnfda at gmail dot com
Summary:Function that always produces legal JSON
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:JSON related
Operating System: OS X 10.6.8
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Having had a month to ruminate on this, and having bounced it off a couple of
userland coders since, I'm going to Won't Fix this from a php-src point of
view, including the possibility of a notice. Having to silence json_encode() to
write E_NOTICE-clean code for a behaviour that many people want and use and
that the reference encoder itself exhibits seems like a bad idea.
I will add a note to the json_encode() manual page specifying that output from
a scalar input may not be interoperable with every JSON implementation, though.
Previous Comments:
[2012-08-05 20:30:45] ajf at ajf dot me
Shouldn't PHP error or warn here? Returning a JSON string with an array
containing the element, instead of just the element passed, is probably not
what
the user expects.
[2012-06-27 02:41:03] arnfda at gmail dot com
It is a weird thing to do, but it's necessary in the case of serving JSON to a
client that won't decode isolated primitives. It could be argued that that's
the
client's problem, but since the spec is ambiguous I'd say it should be given
the
benefit of the doubt. The default behavior of json_encode definitely shouldn't
be
changed, but perhaps another option similar to JSON_FORCE_OBJECT could be
added,
JSON_FORCE_ARRAY maybe?
[2012-06-27 02:07:50] ahar...@php.net
My initial gut feeling is to Won't Fix this: automatically casting a scalar
input
to an array or object is decidedly weird. I guess we could generate a notice to
note that scalar inputs result in non-RFC output.
At any rate, Crockford himself is ambiguous on the validity of isolated JSON
primitives. The RFC grammar doesn't permit them, but the text suggests that
they
may be permitted, the json.org grammar chart doesn't express an opinion, the
reference encoder allows them and encodes and decodes the same way as PHP, and
he
told Joey in an e-mail (after we debated this on IRC a couple of years back and
Joey e-mailed him) that the RFC was only written to associate the MIME type
with
the format and that "it is not the spec". (Joey can presumably furnish the
entire
details of the exchange; I'm quoting him quoting Crockford.)
In summary, even a simple spec like JSON is a bit of a choose your own
adventure.
I wouldn't be completely against a notice, but I don't think we should change
the
behaviour, both for BC and interoperability reasons.
[2012-06-26 14:58:55] arnfda at gmail dot com
Description:
json_encode generates illegal JSON when it is passed a string, boolean, or
number. This behavior is noted here, along with a workaround:
http://www.php.net/manual/en/function.json-encode.php#92817
json_decode accepts the illegal JSON, but other parsers that are more strict do
not (for example, MultiJson in Ruby).
I know the documentation doesn't promise to return valid JSON text, just the
"JSON representation" of whatever is passed into it. So strictly speaking, this
isn't a bug. But it doesn't make sense to have a function that creates JSON
fragments and not one that always produces legal JSON that you can safely pass
to other systems.
It would be great if an option was added to json_encode that forced it to
produce legal JSON strings, e.g. by wrapping single values in brackets as in
the
examples below.
Test script:
---
var_dump(json_encode(1));
var_dump(json_encode(true));
var_dump(json_encode("string"));
Expected result:
string(3) "[1]"
string(6) "[true]"
string(10) "["string"]"
Actual result:
--
string(1) "1"
string(4) "true"
string(8) ""string""
--
Edit this bug report at https://bugs.php.net/bug.php?id=62422&edit=1
Req #55218 [Opn->Csd]: missing a way to know if namespace was declared on current node
Edit report at https://bugs.php.net/bug.php?id=55218&edit=1
ID: 55218
Updated by: ahar...@php.net
Reported by:jerikojerk at gmail dot com
Summary:missing a way to know if namespace was declared on
current node
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:SimpleXML related
Operating System: ubuntu
PHP Version:5.3SVN-2011-07-16 (snap)
-Assigned To:
+Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Merged onto 5.4 and master.
Assigning to Stas because he merged the pull request, but the patch itself came
from Lonny Kapelushnik.
Previous Comments:
[2012-06-28 15:37:06] lonnyk at gmail dot com
Updated the patch on GitHub https://github.com/php/php-src/pull/112
[2012-06-19 22:18:55] renaud dot savalle at gmail dot com
I am working with complex XML files with namespaces declarations spread across
different elements. In particular I need to be able to test if a particular
namespace is declared in a certain node, and as pointed out by the requester,
there is currently no way to do that with SimpleXMLElement. Therefore I would
find Lonny's patch useful for my work and wish it could be included into PHP.
[2011-07-22 23:20:24] lonnyk at gmail dot com
I modified the definition of getDocNamespaces to be:
public array SimpleXMLElement::getDocNamespaces ([ bool $recursive = false [,
bool $from_root = true ] ] )
If the second param is set to true then the method performs exactly as it does
now. If it is set to false it performs as requested.
I choose to modify the method instead of creating a new one because I feel this
is more of a configuration option for the same functionality. If anyone has a
different opinion please let me know.
[2011-07-16 18:45:43] jerikojerk at gmail dot com
Description:
---
>From manual page:
>http://www.php.net/simplexmlelement.getdocnamespaces%23Voir%20aussi
---
There is no way to know when you're on a SimpleXMLElement, if there were a new
namespace declared on current node.
It's due to getDocNamespaces or getNamespaces returning xmlns status for all
the document or document root only.
It's conform to what is described in the documentation but as user we may
expect a different behavior.
Test script:
---
http://example.org/p"; >
http://example.org/t"; >
John Doe
Susie Q. Public
jdslkfjsldk jskdfjsmlkjfkldjkjflskj kljfslkjf sldk
');
//echo '',$x->asXML(),'';
echo "\nrecursive: \n";
//$tmp = $x->getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x->getDocNamespaces(true) ;
var_dump($tmp);
echo "\n\n";
//$tmp = $x->person[0]->getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x->person[0]->getDocNamespaces(true) ;
var_dump($tmp);
echo "\n\n";
//$tmp = $x->person[1]->getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x->person[1]->getDocNamespaces(true) ;
var_dump($tmp);
*/
echo "\nnon recursive: \n";
//$tmp = $x->getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x->getDocNamespaces(false) ;
var_dump($tmp);
echo "\n\n";
//$tmp = $x->person[0]->getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x->person[0]->getDocNamespaces(false) ;
var_dump($tmp);
echo "\n\n";
//$tmp = $x->person[1]->getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x->person[1]->getDocNamespaces(false) ;
var_dump($tmp);
Expected result:
if we were able to provide namespace declare only on current node instead of
root node, the function will provide the following result
recursive:
array(2) { ["p"]=> string(20) "http://example.org/p"; ["t"]=> string(20)
"http://example.org/t"; }
array(1) { ["t"]=> string(20) "http://example.org/t"; }
array(0) { }
non recursive:
array(1) { ["p"]=> string(20) "http://example.org/p"; }
array(1) { ["t"]=> string(20) "http://example.org/t"; }
array(0) { }
Actual result:
--
recursive:
array(2) { ["p"]=> string(20) "http://example.org/p"; ["t"]=> string(20)
"http://example.org/t"; }
array(2) { ["p"]=> string(20) "http://example.org/p"; ["t"]=> string(20)
"http://example.org/t"; }
array(2) { ["p"]=> string(20) "http://example.org/p"; ["t"]=> string(20)
"http://example.org/t"; }
non recursive:
array(1) { ["p"]=> string(20) "http://example.org/p"; }
array(1) { ["p"]=> string(20) "http://example.org/p"; }
array(1) { ["p"]=> string(20) "http://example.org/p"; }
--
Edit this bug report at https://bugs.php.net/bug.php?id=55218&edit=1
Bug #62753 [Opn->Nab]: proxy_test.php
Edit report at https://bugs.php.net/bug.php?id=62753&edit=1
ID: 62753
Updated by: ahar...@php.net
Reported by:admin at angosso dot net
Summary:proxy_test.php
-Status: Open
+Status: Not a bug
Type: Bug
Package:Built-in web server
Operating System: Migration Localhost->_Server
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
I'm sorry, but this is gibberish. I don't know what an SPF record has to do
with anything, there's no description of the "vulnerability", and it doesn't
seem like it's a PHP side issue regardless if you're setting browser settings.
Previous Comments:
[2012-08-05 16:53:44] admin at angosso dot net
Description:
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347
Steps to reproduce:
user_pref("capability.policy.policynames", "strict");
user_pref("capability.policy.strict.sites", "http://www.hosting24.com
http://www.srv47.hosting24.com";);
user_pref("capability.policy.strict.Window.alert", "noAccess");
user_pref("capability.policy.strict.Window.confirm", "noAccess");
user_pref("capability.policy.strict.Window.prompt", "noAccess");
Test script:
---
"v=spf1 +a +mx +ip4:212.1.208.183 +a:srv47.hosting24.com +mx:mail.angosso.net
+mx:srv47.hosting24.com +include:angosso.net ?all"
Expected result:
function _parse_uri()
function _redirect( $uri ) {
$location = $this->_parse_location( $uri );
if ( $location['host'] != $this->host || $location['port'] != $this->port )
{
$this->host = $location['host'];
$this->port = $location['port'];
if ( !$this->_use_proxy) $this->disconnect();
}
usleep( 100 );
$this->get( $location['request_file'] . '?' . $location['query_string'] );
foreach( $this->cookies as $cookie_name => $cookie_data ) {
if ($cookie_data['expires'] > $none) {
$new_cookies[$cookie_name] = $cookie_data;
$domain = preg_quote( $cookie_data['angosso.net'] );
$path = preg_quote( $cookie_data['/home/angosson/public_html/www'] );
if ( preg_match( "'.*$domain$'i", $current_domain ) && preg_match(
"'^$path.*'i", $current_path ) )
$cookie_str .= $cookie_name . '=' .
$cookie_data['http://www.angosso.net/pub-page/economie.php'] . '; ';
}
}
Actual result:
--
Vulnerability
--
Edit this bug report at https://bugs.php.net/bug.php?id=62753&edit=1
Req #42691 [Opn->Csd]: array_reduce: initial parameter should allow non-numeric values
Edit report at https://bugs.php.net/bug.php?id=42691&edit=1 ID: 42691 Updated by: google...@php.net Reported by:tjerk dot meesters at muvee dot com Summary:array_reduce: initial parameter should allow non-numeric values -Status: Open +Status: Closed Type: Feature/Change Request Package:Arrays related Operating System: Linux 2.6 PHP Version:5.2.4 -Assigned To: +Assigned To:googleguy Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-08-05 22:33:41] lonnyk at gmail dot com This has been added in 5.3. I just tested it with PHP 5.4.5-dev and it works. [2007-09-18 02:27:59] tjerk dot meesters at muvee dot com Description: array_reduce() accepts an initial value to be passed as the first argument in the callback function instead of NULL. However, this initial value - if passed - is converted to an int. This is probably because the more common use of this idiom is for mathematical reduction. It would be helpful to allow other types to be passed such as strings or objects. Note: this ticket is a duplicate for #42566, but the reporter never bothered to follow up. Reproduce code: --- Expected result: hello world Actual result: -- 0 world -- Edit this bug report at https://bugs.php.net/bug.php?id=42691&edit=1
Req #62745 [Opn->Wfx]: Extend echo and print possiblity
Edit report at https://bugs.php.net/bug.php?id=62745&edit=1
ID: 62745
Updated by: ahar...@php.net
Reported by:kjelkenes at gmail dot com
Summary:Extend echo and print possiblity
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
-Package:Unknown/Other Function
+Package:Output Control
Operating System: *
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
The commenters are right: output buffering already deals with the feature as
requested, and as Laruence points out, the taint extension is available for the
underlying issue if you want to go down that road.
Closing.
Previous Comments:
[2012-08-05 06:55:18] larue...@php.net
1. if you want taint mode, refer to : http://pecl.php.net/taint
2. if you want escape output: refer to http://www.php.net/manual/en/function.ob-
start.php
thanks
[2012-08-05 05:43:07] phpmpan at mpan dot pl
>From my point of view, keithm provides a solution that does exactly the thing
>you have asked for. Output buffering wasn't created for this purpose, but it
>can be easily used for it without breaking anything. If this is not what you
>wanted, maybe your description is not clear enough?
However this is a solution for a problem that doesn't exist in reality.
1. Most of the data output by scripts should never be escaped.
Yet your idea causes ALL data to be escaped, producing garbage.
2. In few specific cases there are small portions of data from untrusted
sources that should be escaped. In such cases a single call is enough.
What you want to be introduced requires 3 lines of code (enable escaping,
echo, disable escaping) just to make same thing a single function call
could do.
3. Even worse: the concept is perpendicular to echo by design,
but not perpendicular to echo by behaviour. Hence it's a design error.
[2012-08-05 01:23:44] kjelkenes at gmail dot com
For the comment above.
Ok, You don't see the need?
Output buffering is something completely different. Yes you can do the same
with output buffering.. But it still includes the HTML that was not printed by
the parser.
What about this case, do you really think output ob_start() buffering???
ob_start();
getName()?>
This is ALSO cached by output buffer function.
$content = ob_get_flush();
That script... yes .. ob_start() before everything and ob_get_contents() will
return the complete parsed content... but it does NOT intercept the ECHO
statement, meaning if you where about to try parsing:
Meaning Output buffering functions could NEVER intercept the echo statement (
RATHER THE WHOLE THING ) .
What if we wanted to intercept the real echo statement and not the ob_*
functions..
Seriously your comment does not make sense. You are talking about ob_*
functions while this is a whole another case, please don't follow this ticket.
[2012-08-04 19:30:44] keithm at aoeex dot com
You can already accomplish this using output buffering if so desired. I don't
see a need to add anything else into the mix. For example:
--
alert(\'This will never be executed.\')';
--
outputs:
[2012-08-04 14:13:55] kjelkenes at gmail dot com
Description:
This is a feature request regarding the "echo" and "print" functions used in
PHP. The echo/print statement is used for output. As of today there are no way
of extending these statements, leading to potential security risks.
If we could extend the echo function at a given time with a handler/closure
this could really improve the security of PHP.
Say we have the following security risk (XSS injection):
$data = "alert('hi');"; // From db.
echo $data;
Today we need custom functions to escape this such as:
function escape($data){
return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
}
echo escape($data);
What if we could implement a handler for the echo/print statements such as this:
// Define a handler:
$outputHandler = function escape($data){
return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
};
/**
* Sets a output handler for php, it's used in echo and print statements.
* @param string $name The identity of this handler ( Unique )
* @param mixed $outputHandler function name or callback closure to use.
* @param mixed $flags What type of satements to use this function.
*/
add_output_handler('xss_filter',$outputHandler, OutputHandler::F_ECHO |
OutputHa
Req #62267 [Com]: Apache 2.4
Edit report at https://bugs.php.net/bug.php?id=62267&edit=1 ID: 62267 Comment by: iomranic at gmail dot com Reported by:neweracracker at gmail dot com Summary:Apache 2.4 Status: Open Type: Feature/Change Request Package:Apache2 related Operating System: Windows PHP Version:5.3Git-2012-06-08 (snap) Block user comment: N Private report: N New Comment: Well, I've tested my patch on all of the following PHP versions with successful positive results: 5.3.10/5.3.11/5.3.12/5.3.13/5.3.14/5.3.15 5.4.0/5.4.1/5.4.2/5.4.3/5.4.4/5.4.5 What's solved my issue was just one simple modification in your original patch: Replace ||'sapi\\apache2handler');|| With ||'sapi\\apache2_4handler');|| Other modifications in my patch isn't mandatory. Compiled & running successfully without any issues till now. And to be honest, I didn't use Apache's IPv6 features & that's why I didn't care whether or not it's compiled & running or not. P.S. If you can, please delete this patch (posted by mistake): php-5.4-apache-2.4 (last revision 2012-08-05 17:53 UTC) Previous Comments: [2012-08-05 19:59:51] neweracracker at gmail dot com Hello, I had to include php_network.h in my patch because SAPIs for IPv6 enabled apache 2.4 wouldn't build without it. I didn't tested PHP 5.4 yet regarding this. Only PHP 5.3. [2012-08-05 18:04:35] iomranic at gmail dot com This modified patch applicable for both branches 5.4 & 5.3 [2012-08-05 17:51:14] iomranic at gmail dot com Your patch allowed me to compile php5apache2_4.dll successfully, but Apache service failed to start with the following error(s) in event log: >>> httpd.exe: Syntax error on line 175 of /path/to/httpd.conf: Module >>> "sapi\\apache2handler\\mod_php5.c" is not compatible with this version. >>> of Apache (found 20110619, need 20120211). Please contact the vendor for >>> the correct version. After reviewing PHP's source code, I've reached a good solution which worked for me, compilation succeeded, and launching Apache 2.4 with PHP 5.4 module (Apache 2.4 Handler) succeeded as well. Solution attached as a patch file below. Note that I've removed Apache 2.3 support, and added both "Apache 2.4 Filter" & "Apache 2.4 Handler" support. I've removed unwanted "php_network.c" inclusion (that "neweracracker" added in his patch) from the patch as well, since I didn't see any need for it. [2012-06-08 18:09:08] neweracracker at gmail dot com Description: I've implemented a patch for PHP 5.3 that enables Apache 2.4 support -- Edit this bug report at https://bugs.php.net/bug.php?id=62267&edit=1
Req #42691 [Com]: array_reduce: initial parameter should allow non-numeric values
Edit report at https://bugs.php.net/bug.php?id=42691&edit=1 ID: 42691 Comment by: lonnyk at gmail dot com Reported by:tjerk dot meesters at muvee dot com Summary:array_reduce: initial parameter should allow non-numeric values Status: Open Type: Feature/Change Request Package:Arrays related Operating System: Linux 2.6 PHP Version:5.2.4 Block user comment: N Private report: N New Comment: This has been added in 5.3. I just tested it with PHP 5.4.5-dev and it works. Previous Comments: [2007-09-18 02:27:59] tjerk dot meesters at muvee dot com Description: array_reduce() accepts an initial value to be passed as the first argument in the callback function instead of NULL. However, this initial value - if passed - is converted to an int. This is probably because the more common use of this idiom is for mathematical reduction. It would be helpful to allow other types to be passed such as strings or objects. Note: this ticket is a duplicate for #42566, but the reporter never bothered to follow up. Reproduce code: --- Expected result: hello world Actual result: -- 0 world -- Edit this bug report at https://bugs.php.net/bug.php?id=42691&edit=1
Bug #48601 [Com]: xpath() returns FALSE for legitimate query
Edit report at https://bugs.php.net/bug.php?id=48601&edit=1 ID: 48601 Comment by: johnkary at gmail dot com Reported by:theultramage at gmail dot com Summary:xpath() returns FALSE for legitimate query Status: Closed Type: Bug Package:SimpleXML related Operating System: Windows Vista PHP Version:5.4SVN Assigned To:rrichards Block user comment: N Private report: N New Comment: It's not clear exactly which 5.3 release this bug was actually fixed in. I believe I am still encountering this bug in 5.3.8 (on my production server) but do not encounter it with the same code in 5.3.14 (on my dev machine). This was made evident from actual PHP code I wrote using an XPath query. I have not run the core unit tests to confirm this. Just adding notes here about affected versions for those that come across this bug report in the future. Previous Comments: [2012-07-08 11:58:12] theultramage at gmail dot com Yes, at least with current versions (5.4.3 / 5.3.14) this issue no longer occurs. [2011-12-22 08:56:13] me at ktamura dot com I believe this has indeed been fixed. [2011-09-01 13:42:34] chr...@php.net Automatic comment from SVN on behalf of chregu Revision: http://svn.php.net/viewvc/?view=revision&revision=315990 Log: Merge from Trunk simplexml->query returns empty array if no nodes were found and false if libxml thinks the xpath-expression was invalid. Behaves now the same like DomXPath and fixes Bug #48601 Adjusted a test to reflect that change [2011-08-31 11:44:11] chr...@php.net Automatic comment from SVN on behalf of chregu Revision: http://svn.php.net/viewvc/?view=revision&revision=315883 Log: simplexml->query returns empty array if no nodes were found and false if libxml thinks the xpath-expression was invalid. Behaves now the same like DomXPath and fixes Bug #48601 Adjusted a test to reflect that change [2011-08-01 03:21:26] s...@php.net Looks like it still happens for me - the unit test fails and the function returns false. 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=48601 -- Edit this bug report at https://bugs.php.net/bug.php?id=48601&edit=1
Req #62422 [Com]: Function that always produces legal JSON
Edit report at https://bugs.php.net/bug.php?id=62422&edit=1
ID: 62422
Comment by: ajf at ajf dot me
Reported by:arnfda at gmail dot com
Summary:Function that always produces legal JSON
Status: Open
Type: Feature/Change Request
Package:JSON related
Operating System: OS X 10.6.8
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
Shouldn't PHP error or warn here? Returning a JSON string with an array
containing the element, instead of just the element passed, is probably not
what
the user expects.
Previous Comments:
[2012-06-27 02:41:03] arnfda at gmail dot com
It is a weird thing to do, but it's necessary in the case of serving JSON to a
client that won't decode isolated primitives. It could be argued that that's
the
client's problem, but since the spec is ambiguous I'd say it should be given
the
benefit of the doubt. The default behavior of json_encode definitely shouldn't
be
changed, but perhaps another option similar to JSON_FORCE_OBJECT could be
added,
JSON_FORCE_ARRAY maybe?
[2012-06-27 02:07:50] ahar...@php.net
My initial gut feeling is to Won't Fix this: automatically casting a scalar
input
to an array or object is decidedly weird. I guess we could generate a notice to
note that scalar inputs result in non-RFC output.
At any rate, Crockford himself is ambiguous on the validity of isolated JSON
primitives. The RFC grammar doesn't permit them, but the text suggests that
they
may be permitted, the json.org grammar chart doesn't express an opinion, the
reference encoder allows them and encodes and decodes the same way as PHP, and
he
told Joey in an e-mail (after we debated this on IRC a couple of years back and
Joey e-mailed him) that the RFC was only written to associate the MIME type
with
the format and that "it is not the spec". (Joey can presumably furnish the
entire
details of the exchange; I'm quoting him quoting Crockford.)
In summary, even a simple spec like JSON is a bit of a choose your own
adventure.
I wouldn't be completely against a notice, but I don't think we should change
the
behaviour, both for BC and interoperability reasons.
[2012-06-26 14:58:55] arnfda at gmail dot com
Description:
json_encode generates illegal JSON when it is passed a string, boolean, or
number. This behavior is noted here, along with a workaround:
http://www.php.net/manual/en/function.json-encode.php#92817
json_decode accepts the illegal JSON, but other parsers that are more strict do
not (for example, MultiJson in Ruby).
I know the documentation doesn't promise to return valid JSON text, just the
"JSON representation" of whatever is passed into it. So strictly speaking, this
isn't a bug. But it doesn't make sense to have a function that creates JSON
fragments and not one that always produces legal JSON that you can safely pass
to other systems.
It would be great if an option was added to json_encode that forced it to
produce legal JSON strings, e.g. by wrapping single values in brackets as in
the
examples below.
Test script:
---
var_dump(json_encode(1));
var_dump(json_encode(true));
var_dump(json_encode("string"));
Expected result:
string(3) "[1]"
string(6) "[true]"
string(10) "["string"]"
Actual result:
--
string(1) "1"
string(4) "true"
string(8) ""string""
--
Edit this bug report at https://bugs.php.net/bug.php?id=62422&edit=1
Req #62749 [Opn->Wfx]: array_map should call callback with array index
Edit report at https://bugs.php.net/bug.php?id=62749&edit=1
ID: 62749
Updated by: ras...@php.net
Reported by:gmblar+php at gmail dot com
Summary:array_map should call callback with array index
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Arrays related
Operating System: MacOSX
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Changing this would break any app currently using array_map() and the
workaround
is trivial.
Previous Comments:
[2012-08-05 20:08:09] ajf at ajf dot me
Just do array_map($func, $array, array_keys($array));
[2012-08-04 19:19:16] gmblar+php at gmail dot com
Correct expected result:
array(2) {
["foo"]=>
string(2) "23:foo"
["bar"]=>
string(2) "42:bar"
}
[2012-08-04 19:14:23] gmblar+php at gmail dot com
Description:
Add current array index as second argument to the callback of array_map
Test script:
---
23,
'bar' => 42
);
$result = array_map(function() {
return implode(':', func_get_args());
}, $array);
var_dump($result);
Expected result:
array(2) {
["foo"]=>
string(2) "23:foo"
["bar"]=>
string(2) "42:foo"
}
Actual result:
--
array(2) {
["foo"]=>
string(2) "23"
["bar"]=>
string(2) "42"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62749&edit=1
Req #62732 [Com]: [Feature Request]Built-in TCP server
Edit report at https://bugs.php.net/bug.php?id=62732&edit=1
ID: 62732
Comment by: ajf at ajf dot me
Reported by:k at webnfo dot com
Summary:[Feature Request]Built-in TCP server
Status: Open
Type: Feature/Change Request
Package:Built-in web server
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Do you mean a commandline thing like -S?
Or do you mean something like this?
tcp_server("localhost", 9001, function ($addr, $sock) {
// do stuff here
});
Previous Comments:
[2012-08-03 03:32:34] k at webnfo dot com
Description:
TCP server can handle much more protocols not only on http. Like smtp, etc.
Just accept the tcp message and invoke php to handle the other parts.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62732&edit=1
Req #62749 [Com]: array_map should call callback with array index
Edit report at https://bugs.php.net/bug.php?id=62749&edit=1
ID: 62749
Comment by: ajf at ajf dot me
Reported by:gmblar+php at gmail dot com
Summary:array_map should call callback with array index
Status: Open
Type: Feature/Change Request
Package:Arrays related
Operating System: MacOSX
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Just do array_map($func, $array, array_keys($array));
Previous Comments:
[2012-08-04 19:19:16] gmblar+php at gmail dot com
Correct expected result:
array(2) {
["foo"]=>
string(2) "23:foo"
["bar"]=>
string(2) "42:bar"
}
[2012-08-04 19:14:23] gmblar+php at gmail dot com
Description:
Add current array index as second argument to the callback of array_map
Test script:
---
23,
'bar' => 42
);
$result = array_map(function() {
return implode(':', func_get_args());
}, $array);
var_dump($result);
Expected result:
array(2) {
["foo"]=>
string(2) "23:foo"
["bar"]=>
string(2) "42:foo"
}
Actual result:
--
array(2) {
["foo"]=>
string(2) "23"
["bar"]=>
string(2) "42"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62749&edit=1
Req #62267 [Com]: Apache 2.4
Edit report at https://bugs.php.net/bug.php?id=62267&edit=1 ID: 62267 Comment by: neweracracker at gmail dot com Reported by:neweracracker at gmail dot com Summary:Apache 2.4 Status: Open Type: Feature/Change Request Package:Apache2 related Operating System: Windows PHP Version:5.3Git-2012-06-08 (snap) Block user comment: N Private report: N New Comment: Hello, I had to include php_network.h in my patch because SAPIs for IPv6 enabled apache 2.4 wouldn't build without it. I didn't tested PHP 5.4 yet regarding this. Only PHP 5.3. Previous Comments: [2012-08-05 18:04:35] iomranic at gmail dot com This modified patch applicable for both branches 5.4 & 5.3 [2012-08-05 17:51:14] iomranic at gmail dot com Your patch allowed me to compile php5apache2_4.dll successfully, but Apache service failed to start with the following error(s) in event log: >>> httpd.exe: Syntax error on line 175 of /path/to/httpd.conf: Module >>> "sapi\\apache2handler\\mod_php5.c" is not compatible with this version. >>> of Apache (found 20110619, need 20120211). Please contact the vendor for >>> the correct version. After reviewing PHP's source code, I've reached a good solution which worked for me, compilation succeeded, and launching Apache 2.4 with PHP 5.4 module (Apache 2.4 Handler) succeeded as well. Solution attached as a patch file below. Note that I've removed Apache 2.3 support, and added both "Apache 2.4 Filter" & "Apache 2.4 Handler" support. I've removed unwanted "php_network.c" inclusion (that "neweracracker" added in his patch) from the patch as well, since I didn't see any need for it. [2012-06-08 18:09:08] neweracracker at gmail dot com Description: I've implemented a patch for PHP 5.3 that enables Apache 2.4 support -- Edit this bug report at https://bugs.php.net/bug.php?id=62267&edit=1
Req #62267 [Com]: Apache 2.4
Edit report at https://bugs.php.net/bug.php?id=62267&edit=1 ID: 62267 Comment by: iomranic at gmail dot com Reported by:neweracracker at gmail dot com Summary:Apache 2.4 Status: Open Type: Feature/Change Request Package:Apache2 related Operating System: Windows PHP Version:5.3Git-2012-06-08 (snap) Block user comment: N Private report: N New Comment: This modified patch applicable for both branches 5.4 & 5.3 Previous Comments: [2012-08-05 17:51:14] iomranic at gmail dot com Your patch allowed me to compile php5apache2_4.dll successfully, but Apache service failed to start with the following error(s) in event log: >>> httpd.exe: Syntax error on line 175 of /path/to/httpd.conf: Module >>> "sapi\\apache2handler\\mod_php5.c" is not compatible with this version. >>> of Apache (found 20110619, need 20120211). Please contact the vendor for >>> the correct version. After reviewing PHP's source code, I've reached a good solution which worked for me, compilation succeeded, and launching Apache 2.4 with PHP 5.4 module (Apache 2.4 Handler) succeeded as well. Solution attached as a patch file below. Note that I've removed Apache 2.3 support, and added both "Apache 2.4 Filter" & "Apache 2.4 Handler" support. I've removed unwanted "php_network.c" inclusion (that "neweracracker" added in his patch) from the patch as well, since I didn't see any need for it. [2012-06-08 18:09:08] neweracracker at gmail dot com Description: I've implemented a patch for PHP 5.3 that enables Apache 2.4 support -- Edit this bug report at https://bugs.php.net/bug.php?id=62267&edit=1
Req #62267 [Com]: Apache 2.4
Edit report at https://bugs.php.net/bug.php?id=62267&edit=1 ID: 62267 Comment by: iomranic at gmail dot com Reported by:neweracracker at gmail dot com Summary:Apache 2.4 Status: Open Type: Feature/Change Request Package:Apache2 related Operating System: Windows PHP Version:5.3Git-2012-06-08 (snap) Block user comment: N Private report: N New Comment: Your patch allowed me to compile php5apache2_4.dll successfully, but Apache service failed to start with the following error(s) in event log: >>> httpd.exe: Syntax error on line 175 of /path/to/httpd.conf: Module >>> "sapi\\apache2handler\\mod_php5.c" is not compatible with this version. >>> of Apache (found 20110619, need 20120211). Please contact the vendor for >>> the correct version. After reviewing PHP's source code, I've reached a good solution which worked for me, compilation succeeded, and launching Apache 2.4 with PHP 5.4 module (Apache 2.4 Handler) succeeded as well. Solution attached as a patch file below. Note that I've removed Apache 2.3 support, and added both "Apache 2.4 Filter" & "Apache 2.4 Handler" support. I've removed unwanted "php_network.c" inclusion (that "neweracracker" added in his patch) from the patch as well, since I didn't see any need for it. Previous Comments: [2012-06-08 18:09:08] neweracracker at gmail dot com Description: I've implemented a patch for PHP 5.3 that enables Apache 2.4 support -- Edit this bug report at https://bugs.php.net/bug.php?id=62267&edit=1
[PHP-BUG] Bug #62753 [NEW]: proxy_test.php
From: admin at angosso dot net
Operating system: Migration Localhost->_Server
PHP version: 5.3.15
Package: Built-in web server
Bug Type: Bug
Bug description:proxy_test.php
Description:
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20100101
Firefox/14.0.1
Build ID: 20120713134347
Steps to reproduce:
user_pref("capability.policy.policynames", "strict");
user_pref("capability.policy.strict.sites", "http://www.hosting24.com
http://www.srv47.hosting24.com";);
user_pref("capability.policy.strict.Window.alert", "noAccess");
user_pref("capability.policy.strict.Window.confirm", "noAccess");
user_pref("capability.policy.strict.Window.prompt", "noAccess");
Test script:
---
"v=spf1 +a +mx +ip4:212.1.208.183 +a:srv47.hosting24.com
+mx:mail.angosso.net +mx:srv47.hosting24.com +include:angosso.net ?all"
Expected result:
function _parse_uri()
function _redirect( $uri ) {
$location = $this->_parse_location( $uri );
if ( $location['host'] != $this->host || $location['port'] !=
$this->port ) {
$this->host = $location['host'];
$this->port = $location['port'];
if ( !$this->_use_proxy) $this->disconnect();
}
usleep( 100 );
$this->get( $location['request_file'] . '?' . $location['query_string']
);
foreach( $this->cookies as $cookie_name => $cookie_data ) {
if ($cookie_data['expires'] > $none) {
$new_cookies[$cookie_name] = $cookie_data;
$domain = preg_quote( $cookie_data['angosso.net'] );
$path = preg_quote( $cookie_data['/home/angosson/public_html/www'] );
if ( preg_match( "'.*$domain$'i", $current_domain ) && preg_match(
"'^$path.*'i", $current_path ) )
$cookie_str .= $cookie_name . '=' .
$cookie_data['http://www.angosso.net/pub-page/economie.php'] . '; ';
}
}
Actual result:
--
Vulnerability
--
Edit bug report at https://bugs.php.net/bug.php?id=62753&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62753&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62753&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62753&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62753&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62753&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62753&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62753&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62753&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62753&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62753&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62753&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62753&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62753&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62753&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62753&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62753&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62753&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62753&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62753&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62753&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62753&r=mysqlcfg
Bug #62672 [Com]: Error on serialize of ArrayObject
Edit report at https://bugs.php.net/bug.php?id=62672&edit=1
ID: 62672
Comment by: lior dot k at zend dot com
Reported by:t dot weber at interexa dot de
Summary:Error on serialize of ArrayObject
Status: Open
Type: Bug
Package:SPL related
Operating System: Cent OS
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
Please see the attached patch by Yoram Bar-Haim
Previous Comments:
[2012-07-27 16:08:41] j dot henge-ernst at interexa dot de
The problem is that the unserialize of ArrayIterator (and also maybe
ArrayObject or other SPL classes) can not dereference object references.
A simpler Testcase:
getIterator());
$s = serialize($t);
$e = unserialize($s);
Fatal error: Uncaught exception 'UnexpectedValueException' with message 'Error
at offset 13 of 26 bytes' in /tmp/test2.php:5
Stack trace:
#0 [internal function]: ArrayIterator->unserialize('x:i:16777216;r:...')
#1 /tmp/test2.php(5): unserialize('a:2:{i:0;C:11:"...')
#2 {main}
thrown in /tmp/test2.php on line 5
If the order in the array is reversed it works, as now the ArrayObject is only
a reference in the array.
Same behaviour with PHP 5.4.5
[2012-07-27 11:04:48] t dot weber at interexa dot de
Description:
Serialize and direct unserialize of Objects does not work if return value of
ArrayObject::getIterator is contained in parent class (see Test script)
Test script:
---
class ObjA
{
private $_varA;
public function __construct(Iterator $source)
{
$this->_varA = $source;
}
}
class ObjB extends ObjA
{
private $_varB;
public function __construct(ArrayObject $keys)
{
$this->_varB = $keys;
parent::__construct($keys->getIterator());
}
}
$obj = new ObjB(new ArrayObject());
unserialize(serialize($obj));
--
Edit this bug report at https://bugs.php.net/bug.php?id=62672&edit=1
Bug #62726 [Com]: FPM fails to spawn when max_children is set to a high number
Edit report at https://bugs.php.net/bug.php?id=62726&edit=1 ID: 62726 Comment by: wer at wereveal dot com Reported by:olemar...@php.net Summary:FPM fails to spawn when max_children is set to a high number Status: Open Type: Bug Package:FPM related Operating System: Gentoo Linux PHP Version:5.4.5 Block user comment: N Private report: N New Comment: Discovered that I am experiencing the same problem with PHP 5.3.15 on Gentoo. php- fpm refuses to start correctly. It hangs although the child processes are started and continue to work even after kill -9 on the main command /usr/lib/php5.3/bin/php-fpm -y /etc/php/fpm-php5.3/php-fpm.conf -g /var/run/php- fpm-php5.3.pid Changing the pm.max_children did not seem to fix this for me and I am using pm = dynamic. Works fine with PHP 5.3.14 Previous Comments: [2012-08-02 12:07:43] olemar...@php.net Description: With the following parameters set in php-fpm.conf, FPM refuse to start properly. The worker threads are spawned, but hangs and only a kill -9 will stop them. Setting pm.max_children to a lower number works. The exact config works with PHP 5.4.4. pm = static pm.max_children = 500 Some additional information can be found in downstream bug https://bugs.gentoo.org/show_bug.cgi?id=428194 -- Edit this bug report at https://bugs.php.net/bug.php?id=62726&edit=1
Bug #62737 [Ana]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Updated by: larue...@php.net
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
you have to realize that they are two different bugs.
1. dangling pointer ; //this is bad.
2. spl's bug. //this should be fixed later. that is what I am working on. if
throw exception(in disable_class_new) is allowd, this will be easy. but for
NOW,
I don't think so, so yeah, it will be a little tough.
Previous Comments:
[2012-08-05 07:34:55] reeze dot xia at gmail dot com
Hi, laruence,
I use the test case in this bug report. after apply the latest patch(#62744
and the attached one). i got:
Fatal error: Couldn't find implementation for method SplFileObject::__construct
in Unknown on line 0
if any internal's parent class was disabled may cause segfault, I have test
RecursiveArrayIterator (by disable ArrayIterator), it will segfault if not
apply
the patch for #62744, and will leaks after apply the patch. There must be
other classes have the same problem,
even though we fixed this bug, there will really
a lot of them need to be fixed too :( we may need a better way to handle
class disabling.
[2012-08-04 15:14:39] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62737.phpt
Revision: 1344093279
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.phpt&revision=1344093279
[2012-08-04 15:13:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62737.patch
Revision: 1344093237
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.patch&revision=1344093237
[2012-08-04 02:58:23] larue...@php.net
I split the "dangling pointer" bug out to #62744, we can look at this one after
we
fixed that one.
[2012-08-03 16:27:55] larue...@php.net
Actually, I have improved the patch, and I don't know what's your test script?
get_class_vars("splFileObject")?
you can try with the new patch.
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=62737
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
Bug #62737 [Com]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Comment by: reeze dot xia at gmail dot com
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
Hi, laruence,
I use the test case in this bug report. after apply the latest patch(#62744
and the attached one). i got:
Fatal error: Couldn't find implementation for method SplFileObject::__construct
in Unknown on line 0
if any internal's parent class was disabled may cause segfault, I have test
RecursiveArrayIterator (by disable ArrayIterator), it will segfault if not
apply
the patch for #62744, and will leaks after apply the patch. There must be
other classes have the same problem,
even though we fixed this bug, there will really
a lot of them need to be fixed too :( we may need a better way to handle
class disabling.
Previous Comments:
[2012-08-04 15:14:39] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62737.phpt
Revision: 1344093279
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.phpt&revision=1344093279
[2012-08-04 15:13:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62737.patch
Revision: 1344093237
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.patch&revision=1344093237
[2012-08-04 02:58:23] larue...@php.net
I split the "dangling pointer" bug out to #62744, we can look at this one after
we
fixed that one.
[2012-08-03 16:27:55] larue...@php.net
Actually, I have improved the patch, and I don't know what's your test script?
get_class_vars("splFileObject")?
you can try with the new patch.
[2012-08-03 16:23:54] larue...@php.net
sure, I am still working on this, thanks
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=62737
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
