Bug #61046 [Com]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Comment by: arrtedone at gmail dot com
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
Description:
Same here, reproducable, but with memory limit set to 128M (note that i am not
using the provided test script, it crached randomly)
Test script:
-
-
System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC
2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115
GDB backtrace :
---
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at
/usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833 if (UNEXPECTED(prev-next_free_block != mm_block) ||
UNEXPECTED(next-prev_free_block != mm_block)) {
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
Previous Comments:
[2012-02-10 18:08:37] ras...@php.net
Same here. Reproducable on 64-bit Linux with memory_limit set to 512k.
The segfault is here:
zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);
(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8,
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}
Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference
*parent
[2012-02-10 17:46:09] jpa...@php.net
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
[2012-02-10 17:34:21] jpa...@php.net
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
[2012-02-10 17:31:28] ni...@php.net
GDB Stacktrace:
#0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70,
apply_func=0x83c7310 clean_non_persistent_function, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8 0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356
[2012-02-10 17:28:02] ni...@php.net
Description:
The attached test script triggers a segfault. It happens during the shutdown
after the memory limit is reached in the byRef($array) line.
Test script:
---
?php
function byRef($ref) {}
ini_set('memory_limit', '500k');
$array = array_fill(0, 2000, '*');
$ref = $array;
byRef($array);
--
Edit this bug report at
[PHP-BUG] Req #63814 [NEW]: angles parameters in imagefilledarc are integers, they should be float
From: webmaster at fxtop dot com
Operating system: Windows
PHP version: 5.4.9
Package: GD related
Bug Type: Feature/Change Request
Bug description:angles parameters in imagefilledarc are integers, they should
be float
Description:
see sample result at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3
angles are truncated to nearest integer, in imagefilledarc function, they
shouldn't
you can change parameter if you like
---
From manual page:
http://www.php.net/function.imagefilledarc#refsect1-function.imagefilledarc-description
---
Test script:
---
header(Content-type: image/jpeg);
if (isset($_GET[DEGRE])){ $lDegre=$_GET[DEGRE];}
$lSizeX=916;
$lSizeY=945;
$image = imagecreatetruecolor($lSizeX, $lSizeY);
$colorGreen = imagecolorallocate($image, 0, 255, 0);
// background coming from
http://commons.wikimedia.org/wiki/File:Protractor_katomierz.jpg with some
little changes
$fond=imagecreatefromjpeg(Protractor_katomierz_tourne05b.jpg);
//HERE I ROUND DEGRE PARAMETER BECAUSE imagefilledarc only accept integers
(I prefer it rounded than truncated)
$lNumDegre=round($lDegre);
$lResult|=imagefilledarc ($image , 460 , 474 , 2*430 , 2*430 , -$lNumDegre
, 0, $colorGreen , IMG_ARC_PIE );
$lResult|=imagecopymerge($image, $fond, 0, 0, 0 , 0, $lSizeX,$lSizeY,75);
imagejpeg($image, temp.jpg);
imagedestroy($image);
echo file_get_contents(temp.jpg);
Expected result:
imagefilledarc should accept float parameters for start and end
parameters.
As you can see on sample at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3 green backgound
allways fall on a degre graduation of the protactor.
--
Edit bug report at https://bugs.php.net/bug.php?id=63814edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63814r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63814r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63814r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63814r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63814r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63814r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63814r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63814r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63814r=support
Expected behavior: https://bugs.php.net/fix.php?id=63814r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63814r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63814r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63814r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63814r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63814r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63814r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63814r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63814r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63814r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63814r=mysqlcfg
Req #63284 [Com]: Please upgrade PCRE
Edit report at https://bugs.php.net/bug.php?id=63284edit=1 ID: 63284 Comment by: nicolas dot grekas+php at gmail dot com Reported by:danielklein at airpost dot net Summary:Please upgrade PCRE Status: Closed Type: Feature/Change Request Package:PCRE related PHP Version:5.4.7 Assigned To:ab Block user comment: N Private report: N New Comment: Version 8.32 is out ! http://vcs.pcre.org/viewvc/code/tags/pcre-8.32/ Previous Comments: [2012-10-19 08:34:14] a...@php.net Thanks for testing ) @danielklein Theoretically it can be done, depends how much of other things one has on the plate right now. If you're highly interested having the newest PCRE, monitor it and do requests - later or sooner they'll be taken on ) [2012-10-19 08:05:56] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=276c5de0d86abab52a19f489dd74565fdec0d3ca Log: Fixed bug #63284 PCRE upgrade to 8.31 [2012-10-19 01:32:42] mattfic...@php.net I built PHP_5_4 (newest snapshot) with your patch. I tested it with all the PHPTs (all, including the PCRE tests) and all the PHPUnit tests from Joomla and found no regressions. I got no additional test failures after I applied your patch. [2012-10-18 23:43:17] danielklein at airpost dot net Can the latest PCRE be included in PHP every time it's released? [2012-10-18 14:44:12] a...@php.net Well, if you look at the PCRE release frequency, it vary from one month to one year. 8.32 will surely come some when :) 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=63284 -- Edit this bug report at https://bugs.php.net/bug.php?id=63284edit=1
Bug #63073 [Com]: master make install fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073edit=1 ID: 63073 Comment by: korvin1986 at gmail dot com Reported by:php at bof dot de Summary:master make install fails to install PEAR Status: Feedback Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit PHP Version:5.5 Block user comment: N Private report: N New Comment: I've tried PHP-5.5.0alpha2 and go-pear.phar script (http://pear.php.net/go-pear.phar) : Log: /usr/bin/php go-pear.phar Below is a suggested file layout for your new PEAR installation. To change individual locations, type the number in front of the directory. Type 'all' to change all of them or simply press Enter to accept these locations. 1. Installation base ($prefix) : /usr 2. Temporary directory for processing: /tmp/pear/install 3. Temporary directory for downloads : /tmp/pear/install 4. Binaries directory: /usr/bin 5. PHP code directory ($php_dir) : /usr/share/pear 6. Documentation directory : /usr/docs 7. Data directory: /usr/data 8. User-modifiable configuration files directory : /usr/cfg 9. Public Web Files directory: /usr/www 10. Tests directory : /usr/tests 11. Name of configuration file: /etc/pear.conf 1-11, 'all' or Enter to continue: Beginning install... Configuration written to /etc/pear.conf... Initialized registry... Preparing to install... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Archive_Tar-1.3.7.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Console_Getopt-1.3.0.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/PEAR-1.9.4.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Structures_Graph-1.0.4.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/XML_Util-1.2.1.tar... could not extract the package.xml file from phar://go-pear.phar/PEAR/go-pear-tarballs/Archive_Tar-1.3.7.tar could not extract the package.xml file from phar://go-pear.phar/PEAR/go-pear-tarballs/Console_Getopt-1.3.0.tar could not extract the package.xml file from phar://go-pear.phar/PEAR/go-pear-tarballs/PEAR-1.9.4.tar could not extract the package.xml file from phar://go-pear.phar/PEAR/go-pear-tarballs/Structures_Graph-1.0.4.tar could not extract the package.xml file from phar://go-pear.phar/PEAR/go-pear-tarballs/XML_Util-1.2.1.tar install failed Previous Comments: [2012-12-06 08:08:54] paj...@php.net It will be much easier to debug if you could provide a small script, even using a pear package as input. [2012-12-06 04:55:49] dani...@php.net This needs to be fixed so PHP 5.5 can be properly tested. Things work as expected when building PHP = 5.4. [2012-10-14 11:06:27] bobvin at pillars dot net Branch master does not compile and also is missing file sapi/fpm/php- fpm.service.in Running git-bisect to find the break point, This is the commit that broke compilation: commit 4968fa644b0849321e1761e52b8db15dd46f9b75 Author: theanomaly...@gmail.com googleguy@googleguy-virtualbox.(none) Date: Tue Apr 17 07:31:36 2012 -0400 Fixed bug #61038; Z and better behavior for unpack() Added new Z argument to pack/unpack, now allowing a to return data without stripping, and A strips all trailing white space, while Z will strip everything after the first null. [2012-09-12 15:30:17] php at bof dot de Description: I'm building PHP master from current git (at 5246d6f02e52798e343bd5208692f1a5ed89b9d9) Compile works fine, but on make install, PEAR does not install. See Actual result regarding the error output I get. I can successfully compile AND install, with identical configure, the PHP-5.4.6 release, so I don't think that there is anything wrong with my build environment. I tried to copy over pecl, pear, and the pear environment, from the 5.4 build/install. pecl and pear search works. download or install fetches the file, but then fails with a similar could not extract error. Test script: --- make install Expected result: Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar- already installed: 1.3.7 [PEAR] Console_Getopt - already installed: 1.3.0 [PEAR] Structures_Graph- already installed: 1.0.4 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.9.4 Actual result: -- Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar: could not extract the
[PHP-BUG] Req #63815 [NEW]: please provide a shortcut language syntax
From: php at lool dot fr Operating system: all PHP version: Irrelevant Package: *General Issues Bug Type: Feature/Change Request Bug description:please provide a shortcut language syntax Description: it is both long to write and difficult to read to have many lines like this in the source code: $value = isset($_POST['blabla']) ? $_POST['blabla'] : 'init_value'; it would be easier to have something like: $value = isnotset($var,'init_value'); -- Edit bug report at https://bugs.php.net/bug.php?id=63815edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63815r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63815r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63815r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63815r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63815r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63815r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63815r=needscript Try newer version: https://bugs.php.net/fix.php?id=63815r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63815r=support Expected behavior: https://bugs.php.net/fix.php?id=63815r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63815r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63815r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63815r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63815r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63815r=dst IIS Stability: https://bugs.php.net/fix.php?id=63815r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63815r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63815r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63815r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63815r=mysqlcfg
Req #63815 [Opn-Nab]: please provide a shortcut language syntax
Edit report at https://bugs.php.net/bug.php?id=63815edit=1 ID: 63815 Updated by: paj...@php.net Reported by:php at lool dot fr Summary:please provide a shortcut language syntax -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Use the ?: operator: $v = $_POST['blabla'] ?: 'init_value'; Previous Comments: [2012-12-20 14:42:04] php at lool dot fr Description: it is both long to write and difficult to read to have many lines like this in the source code: $value = isset($_POST['blabla']) ? $_POST['blabla'] : 'init_value'; it would be easier to have something like: $value = isnotset($var,'init_value'); -- Edit this bug report at https://bugs.php.net/bug.php?id=63815edit=1
Bug #61046 [PATCH]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Patch added by: larue...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61046.patch
Revision: 1356016047
URL:
https://bugs.php.net/patch-display.php?bug=61046patch=bug61046.patchrevision=1356016047
Previous Comments:
[2012-12-20 11:18:02] arrtedone at gmail dot com
Description:
Same here, reproducable, but with memory limit set to 128M (note that i am not
using the provided test script, it crached randomly)
Test script:
-
-
System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC
2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115
GDB backtrace :
---
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at
/usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833 if (UNEXPECTED(prev-next_free_block != mm_block) ||
UNEXPECTED(next-prev_free_block != mm_block)) {
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
[2012-02-10 18:08:37] ras...@php.net
Same here. Reproducable on 64-bit Linux with memory_limit set to 512k.
The segfault is here:
zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);
(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8,
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}
Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference
*parent
[2012-02-10 17:46:09] jpa...@php.net
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
[2012-02-10 17:34:21] jpa...@php.net
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
[2012-02-10 17:31:28] ni...@php.net
GDB Stacktrace:
#0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70,
apply_func=0x83c7310 clean_non_persistent_function, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8 0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356
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=61046
--
Edit this bug
Bug #61046 [Opn-Fbk]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Updated by: larue...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
quick fix attached, could you please verify it?
Previous Comments:
[2012-12-20 15:07:27] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61046.patch
Revision: 1356016047
URL:
https://bugs.php.net/patch-display.php?bug=61046patch=bug61046.patchrevision=1356016047
[2012-12-20 11:18:02] arrtedone at gmail dot com
Description:
Same here, reproducable, but with memory limit set to 128M (note that i am not
using the provided test script, it crached randomly)
Test script:
-
-
System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC
2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115
GDB backtrace :
---
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at
/usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833 if (UNEXPECTED(prev-next_free_block != mm_block) ||
UNEXPECTED(next-prev_free_block != mm_block)) {
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
[2012-02-10 18:08:37] ras...@php.net
Same here. Reproducable on 64-bit Linux with memory_limit set to 512k.
The segfault is here:
zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);
(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8,
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}
Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference
*parent
[2012-02-10 17:46:09] jpa...@php.net
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
[2012-02-10 17:34:21] jpa...@php.net
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
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=61046
--
Edit this bug report at https://bugs.php.net/bug.php?id=61046edit=1
Req #63815 [Nab]: please provide a shortcut language syntax
Edit report at https://bugs.php.net/bug.php?id=63815edit=1 ID: 63815 User updated by:php at lool dot fr Reported by:php at lool dot fr Summary:please provide a shortcut language syntax Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: using $v = $_POST['blabla'] ?: 'init_value'; produces an error: Notice: Undefined index 'blabla' ... the call to isset is also important to distinguish between an empty value and a not set value!!! Previous Comments: [2012-12-20 14:59:53] paj...@php.net Use the ?: operator: $v = $_POST['blabla'] ?: 'init_value'; [2012-12-20 14:42:04] php at lool dot fr Description: it is both long to write and difficult to read to have many lines like this in the source code: $value = isset($_POST['blabla']) ? $_POST['blabla'] : 'init_value'; it would be easier to have something like: $value = isnotset($var,'init_value'); -- Edit this bug report at https://bugs.php.net/bug.php?id=63815edit=1
Req #63814 [Com]: angles parameters in imagefilledarc are integers, they should be float
Edit report at https://bugs.php.net/bug.php?id=63814edit=1
ID: 63814
Comment by: r...@php.net
Reported by:webmaster at fxtop dot com
Summary:angles parameters in imagefilledarc are integers,
they should be float
Status: Open
Type: Feature/Change Request
Package:GD related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
the gd extension is mostly a wrapper for gd library.
As gd library doesn't accept float values for this comment, I think this is not
possible.
Previous Comments:
[2012-12-20 12:32:55] webmaster at fxtop dot com
Description:
see sample result at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3
angles are truncated to nearest integer, in imagefilledarc function, they
shouldn't
you can change parameter if you like
---
From manual page:
http://www.php.net/function.imagefilledarc#refsect1-function.imagefilledarc-description
---
Test script:
---
header(Content-type: image/jpeg);
if (isset($_GET[DEGRE])){ $lDegre=$_GET[DEGRE];}
$lSizeX=916;
$lSizeY=945;
$image = imagecreatetruecolor($lSizeX, $lSizeY);
$colorGreen = imagecolorallocate($image, 0, 255, 0);
// background coming from
http://commons.wikimedia.org/wiki/File:Protractor_katomierz.jpg with some
little changes
$fond=imagecreatefromjpeg(Protractor_katomierz_tourne05b.jpg);
//HERE I ROUND DEGRE PARAMETER BECAUSE imagefilledarc only accept integers (I
prefer it rounded than truncated)
$lNumDegre=round($lDegre);
$lResult|=imagefilledarc ($image , 460 , 474 , 2*430 , 2*430 , -$lNumDegre ,
0, $colorGreen , IMG_ARC_PIE );
$lResult|=imagecopymerge($image, $fond, 0, 0, 0 , 0, $lSizeX,$lSizeY,75);
imagejpeg($image, temp.jpg);
imagedestroy($image);
echo file_get_contents(temp.jpg);
Expected result:
imagefilledarc should accept float parameters for start and end parameters.
As you can see on sample at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3 green backgound
allways fall on a degre graduation of the protactor.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63814edit=1
Bug #61046 [Fbk]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Updated by: larue...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Feedback
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
another way to fix this is promote the ht point assignment in ctor(list blow),
but there is still a chance that alloc failed when try to alloc memory for ht.
so I still think the fix I attached is the better one.
diff --git a/Zend/zend_variables.c b/Zend/zend_variables.c
index 25a66a1..bb6927a 100644
--- a/Zend/zend_variables.c
+++ b/Zend/zend_variables.c
@@ -134,9 +134,9 @@ ZEND_API void _zval_copy_ctor_func(zval *zvalue
ZEND_FILE_LINE_DC)
return; /* do nothing */
}
ALLOC_HASHTABLE_REL(tmp_ht);
+ zvalue-value.ht = tmp_ht;
zend_hash_init(tmp_ht,
zend_hash_num_elements(original_ht), NULL, ZVAL_PTR_DTOR, 0);
zend_hash_copy(tmp_ht, original_ht,
(copy_ctor_func_t) zval_add_ref, (void *) tmp, sizeof(zval *));
- zvalue-value.ht = tmp_ht;
}
break;
case IS_OBJECT:
Previous Comments:
[2012-12-20 15:08:30] larue...@php.net
quick fix attached, could you please verify it?
[2012-12-20 15:07:27] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61046.patch
Revision: 1356016047
URL:
https://bugs.php.net/patch-display.php?bug=61046patch=bug61046.patchrevision=1356016047
[2012-12-20 11:18:02] arrtedone at gmail dot com
Description:
Same here, reproducable, but with memory limit set to 128M (note that i am not
using the provided test script, it crached randomly)
Test script:
-
-
System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC
2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115
GDB backtrace :
---
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at
/usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833 if (UNEXPECTED(prev-next_free_block != mm_block) ||
UNEXPECTED(next-prev_free_block != mm_block)) {
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
[2012-02-10 18:08:37] ras...@php.net
Same here. Reproducable on 64-bit Linux with memory_limit set to 512k.
The segfault is here:
zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);
(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8,
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}
Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference
*parent
[2012-02-10 17:46:09] jpa...@php.net
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
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=61046
--
Edit this bug report at https://bugs.php.net/bug.php?id=61046edit=1
[PHP-BUG] Bug #63816 [NEW]: implementation child interface and after parent cause fatal error.
From: kotlyar dot maksim at gmail dot com
Operating system: linux
PHP version: 5.4.10
Package: Scripting Engine problem
Bug Type: Bug
Bug description:implementation child interface and after parent cause fatal
error.
Description:
Order of implemented interfaces should make any difference. But it is not
the
case. If I implement child interface and parent after I will get a fatal
error
Test script:
---
?php
ini_set('display_errors', 1);
error_reporting(-1);
interface RootInterface
{
function foo();
}
interface FirstChildInterface extends RootInterface
{
function foo();
}
interface SecondChildInterface extends RootInterface
{
function foo();
}
//works fine.
class A implements FirstChildInterface, SecondChildInterface
{
function foo()
{
}
}
//also ok.
class B implements RootInterface, FirstChildInterface
{
function foo()
{
}
}
//there is a fatal error.
class C implements FirstChildInterface, RootInterface
{
function foo()
{
}
}
Expected result:
Should work without errors(as previous examples).
Actual result:
--
PHP Fatal error: Class C cannot implement previously implemented interface
RootInterface in /foo/test.php on line 35
PHP Stack trace:
PHP 1. {main}() /foo/test.php:0
Fatal error: Class C cannot implement previously implemented interface
RootInterface in /foo/test.php on line 35
Call Stack:
0.0008 238784 1. {main}() /foo/test.php:0
--
Edit bug report at https://bugs.php.net/bug.php?id=63816edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63816r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63816r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63816r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63816r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63816r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63816r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63816r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63816r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63816r=support
Expected behavior: https://bugs.php.net/fix.php?id=63816r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63816r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63816r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63816r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63816r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63816r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63816r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63816r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63816r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63816r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63816r=mysqlcfg
Bug #63816 [Opn]: implementation child interface and after parent cause fatal error.
Edit report at https://bugs.php.net/bug.php?id=63816edit=1
ID: 63816
User updated by:kotlyar dot maksim at gmail dot com
Reported by:kotlyar dot maksim at gmail dot com
Summary:implementation child interface and after parent
cause fatal error.
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: linux
-PHP Version:5.4.10
+PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
Change php version
Previous Comments:
[2012-12-20 15:29:23] kotlyar dot maksim at gmail dot com
Description:
Order of implemented interfaces should make any difference. But it is not the
case. If I implement child interface and parent after I will get a fatal error
Test script:
---
?php
ini_set('display_errors', 1);
error_reporting(-1);
interface RootInterface
{
function foo();
}
interface FirstChildInterface extends RootInterface
{
function foo();
}
interface SecondChildInterface extends RootInterface
{
function foo();
}
//works fine.
class A implements FirstChildInterface, SecondChildInterface
{
function foo()
{
}
}
//also ok.
class B implements RootInterface, FirstChildInterface
{
function foo()
{
}
}
//there is a fatal error.
class C implements FirstChildInterface, RootInterface
{
function foo()
{
}
}
Expected result:
Should work without errors(as previous examples).
Actual result:
--
PHP Fatal error: Class C cannot implement previously implemented interface
RootInterface in /foo/test.php on line 35
PHP Stack trace:
PHP 1. {main}() /foo/test.php:0
Fatal error: Class C cannot implement previously implemented interface
RootInterface in /foo/test.php on line 35
Call Stack:
0.0008 238784 1. {main}() /foo/test.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=63816edit=1
Bug #63769 [Com]: file:// protocol does not support percent-encoded characters
Edit report at https://bugs.php.net/bug.php?id=63769edit=1
ID: 63769
Comment by: anon at anon dot anon
Reported by:hanskrentel at yahoo dot de
Summary:file:// protocol does not support percent-encoded
characters
Status: Not a bug
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not*
work.
Unfortunately it does work, if you create a file literally named
catalog%202.xml. PHP's behavior is broken but it's impossible to alter it
without breaking compatibility.
Previous Comments:
[2012-12-17 14:55:51] hanskrentel at yahoo dot de
I beg your pardon, but if both are perfectly valid filenames, the fs function
behaviour is broken (and not correct), because it does not work with both
perfectly valid filenames:
The path file:///C:/temp/catalog%202.xml (without the quotes) does *not* work.
The request is to remove this shortcoming and have it work. I thought this was
clear from the initial report. Please let me know how I can further assist with
this.
[2012-12-15 11:12:14] a...@php.net
Since both catalog%202.xml and catalog 2.xml are perfectly valid filenames,
the fs function behaviour is correct. The user can decide where it's needed url
encoded and where it's not.
[2012-12-14 15:51:57] hanskrentel at yahoo dot de
Description:
Using a file-URI containing characters that are percent-encoded (one byte/octet
is encoded as a character triplet, e.g. Space - %20) do not work. The URI is
not properly decoded.
Consider the following file on disk:
c:\temp\catalog 2.xml
PHP is able to find it existing via:
is_file('file:///C:/temp/catalog 2.xml');
However, commonly that file is written as:
file:///C:/temp/catalog%202.xml
And using that filename in PHP via:
is_file('file:///C:/temp/catalog%202.xml');
gives FALSE.
(Example is a libxml catalog file, properly specified for libxml)
When you're looking into this, it might be worth to also look for + as encoding
for space - just not that this case gets overlooked.
Test script:
---
?php
touch($name = 'catalog 2.xml');
$uri = sprintf('file:///%s/%s', strtr(__DIR__, ['\\' = '/', ' ' = '%20']),
rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));
Expected result:
OK - file:///C:/temp/catalog%202.xml (1)
Actual result:
--
FAIL - file:///C:/temp/catalog%202.xml (1)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63769edit=1
Req #63815 [Com]: please provide a shortcut language syntax
Edit report at https://bugs.php.net/bug.php?id=63815edit=1
ID: 63815
Comment by: ni...@php.net
Reported by:php at lool dot fr
Summary:please provide a shortcut language syntax
Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Userland implementation of said function:
function isnotset($var, $default) {
if (isset($var)) {
return $var;
} else {
return $default;
}
}
Previous Comments:
[2012-12-20 15:10:23] php at lool dot fr
using $v = $_POST['blabla'] ?: 'init_value';
produces an error:
Notice: Undefined index 'blabla' ...
the call to isset is also important to distinguish between an empty value and a
not set value!!!
[2012-12-20 14:59:53] paj...@php.net
Use the ?: operator:
$v = $_POST['blabla'] ?: 'init_value';
[2012-12-20 14:42:04] php at lool dot fr
Description:
it is both long to write and difficult to read to have many lines like this in
the source code:
$value = isset($_POST['blabla']) ? $_POST['blabla'] : 'init_value';
it would be easier to have something like:
$value = isnotset($var,'init_value');
--
Edit this bug report at https://bugs.php.net/bug.php?id=63815edit=1
Req #63815 [Nab]: please provide a shortcut language syntax
Edit report at https://bugs.php.net/bug.php?id=63815edit=1
ID: 63815
User updated by:php at lool dot fr
Reported by:php at lool dot fr
Summary:please provide a shortcut language syntax
Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
the purpose of a language syntax shortcut is both functionnality and
performance.
currently, 2 array access to the same element is necessary, as with built-in
implementation, only 1 access will be done!
I do not even mention of a function call overhead!
Previous Comments:
[2012-12-20 16:34:03] ni...@php.net
Userland implementation of said function:
function isnotset($var, $default) {
if (isset($var)) {
return $var;
} else {
return $default;
}
}
[2012-12-20 15:10:23] php at lool dot fr
using $v = $_POST['blabla'] ?: 'init_value';
produces an error:
Notice: Undefined index 'blabla' ...
the call to isset is also important to distinguish between an empty value and a
not set value!!!
[2012-12-20 14:59:53] paj...@php.net
Use the ?: operator:
$v = $_POST['blabla'] ?: 'init_value';
[2012-12-20 14:42:04] php at lool dot fr
Description:
it is both long to write and difficult to read to have many lines like this in
the source code:
$value = isset($_POST['blabla']) ? $_POST['blabla'] : 'init_value';
it would be easier to have something like:
$value = isnotset($var,'init_value');
--
Edit this bug report at https://bugs.php.net/bug.php?id=63815edit=1
[PHP-BUG] Req #63818 [NEW]: Need option to search in array keys instead of values
From: dkadosh at affinegy dot com
Operating system: any
PHP version: 5.3.20
Package: PCRE related
Bug Type: Feature/Change Request
Bug description:Need option to search in array keys instead of values
Description:
---
From manual page: http://www.php.net/function.preg-grep
---
I'm asking for an extra flag to this function, to cause it to do its search
in the array keys rather than in the values.
While there's a comment in the above page of how to post-process
preg_grep() results to achieve this, I'd rather it be done in C (inside the
PCRE code) than PHP for performance reasons.
I thought about something like this:
$a = array_flip( preg_grep('/Version$/', array_flip($aParams)) );
which would almost return what I want, HOWEVER it has two problems:
1) If certain values of $aParams are duplicated, the first array_flip()
will lose those rows in the array.
2) I'd incur a sizeable CPU and memory hit by calling array_flip, which
duplicates the array(s) in RAM.
Test script:
---
The current work-around:
function preg_grep_keys( $pattern, $input, $flags = 0 )
{
$keys = preg_grep( $pattern, array_keys( $input ), $flags );
$vals = array();
foreach ( $keys as $key )
{
$vals[$key] = $input[$key];
}
return $vals;
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63818edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63818r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63818r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63818r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63818r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63818r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63818r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63818r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63818r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63818r=support
Expected behavior: https://bugs.php.net/fix.php?id=63818r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63818r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63818r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63818r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63818r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63818r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63818r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63818r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63818r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63818r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63818r=mysqlcfg
[PHP-BUG] Bug #63819 [NEW]: 5.4.10 package seems incomplete and non-functional
From: spause at gmail dot com Operating system: N/A PHP version: 5.4.10 Package: *General Issues Bug Type: Bug Bug description:5.4.10 package seems incomplete and non-functional Description: Current windows package for php-5.4.10-nts-Win32-VC9-x86.zip appears to be incomplete. A standalone install of this package fails to work for at least one application that was able to function on 5.4.8. Only by merging the contents of this zip with 5.4.8 was I able to get the application to function. I suspect some files were accidentally left out of this 5.4.10 package. Please note the significant discrepancy in file sizes Affected file: http://windows.php.net/downloads/releases/php-5.4.10-nts-Win32-VC9-x86.zip File size: 16507699 Previous version: http://windows.php.net/downloads/releases/archives/php-5.4.9-nts-Win32-VC9-x86.zip File size: 23264651 -- Edit bug report at https://bugs.php.net/bug.php?id=63819edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63819r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63819r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63819r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63819r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63819r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63819r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63819r=needscript Try newer version: https://bugs.php.net/fix.php?id=63819r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63819r=support Expected behavior: https://bugs.php.net/fix.php?id=63819r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63819r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63819r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63819r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63819r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63819r=dst IIS Stability: https://bugs.php.net/fix.php?id=63819r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63819r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63819r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63819r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63819r=mysqlcfg
[PHP-BUG] Bug #63820 [NEW]: Parallel search does not accept array of attribute arrays
From: rr dot rossmann at me dot com Operating system: OS X PHP version: 5.4.10 Package: LDAP related Bug Type: Bug Bug description:Parallel search does not accept array of attribute arrays Description: When doing an ldap parallel search, it is not possible to specify the attributes I want to retrieve per-query, only per operation. I want to read a set of properties for a read operation of i.e. OU=Computers,DC=example,DC=com and a different set of properties for OU=Users,DC=example,DC=com . I want to do a parallel read operation by combining all the query parameters (links, search bases etc.) into arrays, but I cannot group the attributes arrays as such; I can only provide one array with the attributes, otherwise only DN is returned in the resultset. Test script: --- $con = ldap_connect( 'example.com' ); ldap_set_option( $con, LDAP_OPT_PROTOCOL_VERSION, 3 ); ldap_set_option( $con, LDAP_OPT_REFERRALS, 0 ); ldap_bind( $con, 'User', 'password' ); // use the same connection for both read queries $connections = array( $con, $con ); // Read attribs from Computers and Users containers $dns = array( 'OU=Computers,DC=example,DC=com', 'OU=Users,DC=example,DC=com' ); // Needed for the read operation $filters = array( '(objectclass=*)', '(objectclass=*)' ); $attribSet1 = array( 'name', 'objectclass' ); // attribs I want from Computers $attribSet2 = array( 'cn', 'objectcategory' ); // attribs I want from Users // Combining the attributes like this causes the erroneous behaviour $getThese = array( $attribSet1 , $attribSet2 ); // Do a parallel read operation $result_ids = ldap_read( $connections, $dns, $filters, $getThese ); $data0 = ldap_get_entries( $con, $result_ids[0] ); $data1 = ldap_get_entries( $con, $result_ids[1] ); print_r( $data0 ); // Only DN attribute retrieved print_r( $data1 ); // Only DN attribute retrieved /* Doing the read query like this works, but I have to specify the attribute set for the whole operation: $result_ids = ldap_read( $connections, $dns, $filters, $getThese[0] ); */ Expected result: for print_r( $data0 ); I expect to have these attributes present: name, objectclass for print_r( $data1 ); I expect to have these attributes present: cn, objectcategory Actual result: -- I get only dn attribute, which is returned for every ldap query -- Edit bug report at https://bugs.php.net/bug.php?id=63820edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63820r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63820r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63820r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63820r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63820r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63820r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63820r=needscript Try newer version: https://bugs.php.net/fix.php?id=63820r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63820r=support Expected behavior: https://bugs.php.net/fix.php?id=63820r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63820r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63820r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63820r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63820r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63820r=dst IIS Stability: https://bugs.php.net/fix.php?id=63820r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63820r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63820r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63820r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63820r=mysqlcfg
[PHP-BUG] Bug #63821 [NEW]: incorrect pi value
From: sandaq at gmail dot com
Operating system: linux
PHP version: 5.3.20
Package: Math related
Bug Type: Bug
Bug description:incorrect pi value
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit bug report at https://bugs.php.net/bug.php?id=63821edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63821r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63821r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63821r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63821r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63821r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63821r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63821r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63821r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63821r=support
Expected behavior: https://bugs.php.net/fix.php?id=63821r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63821r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63821r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63821r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63821r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63821r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63821r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63821r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63821r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63821r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63821r=mysqlcfg
Bug #63819 [Opn-Asn]: 5.4.10 package seems incomplete and non-functional
Edit report at https://bugs.php.net/bug.php?id=63819edit=1 ID: 63819 Updated by: johan...@php.net Reported by:spause at gmail dot com Summary:5.4.10 package seems incomplete and non-functional -Status: Open +Status: Assigned Type: Bug Package:*General Issues Operating System: N/A PHP Version:5.4.10 -Assigned To: +Assigned To:szarkos Block user comment: N Private report: N Previous Comments: [2012-12-20 17:38:43] spause at gmail dot com Description: Current windows package for php-5.4.10-nts-Win32-VC9-x86.zip appears to be incomplete. A standalone install of this package fails to work for at least one application that was able to function on 5.4.8. Only by merging the contents of this zip with 5.4.8 was I able to get the application to function. I suspect some files were accidentally left out of this 5.4.10 package. Please note the significant discrepancy in file sizes Affected file: http://windows.php.net/downloads/releases/php-5.4.10-nts-Win32-VC9-x86.zip File size: 16507699 Previous version: http://windows.php.net/downloads/releases/archives/php-5.4.9-nts-Win32-VC9-x86.zip File size: 23264651 -- Edit this bug report at https://bugs.php.net/bug.php?id=63819edit=1
Bug #63821 [Opn-Csd]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821edit=1
ID: 63821
Updated by: bj...@php.net
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
-Status: Open
+Status: Closed
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
-Assigned To:
+Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
Previous Comments:
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821edit=1
Bug #63821 [Csd]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821edit=1
ID: 63821
User updated by:sandaq at gmail dot com
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
Status: Closed
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
My distro is centos and pi is defined in math.h as correct value:
3.1415926535897932384626433832795029L
This happens on winxp also
Previous Comments:
[2012-12-20 22:08:31] bj...@php.net
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821edit=1
Bug #63821 [Csd]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821edit=1
ID: 63821
User updated by:sandaq at gmail dot com
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
Status: Closed
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
also tested on 3 different linux centos and 1 debian all with defined correct
value of pi in math.h, all gave the same wrong output.
Previous Comments:
[2012-12-20 22:17:08] sandaq at gmail dot com
My distro is centos and pi is defined in math.h as correct value:
3.1415926535897932384626433832795029L
This happens on winxp also
[2012-12-20 22:08:31] bj...@php.net
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821edit=1
Bug #63821 [Csd-Asn]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821edit=1
ID: 63821
User updated by:sandaq at gmail dot com
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
-Status: Closed
+Status: Assigned
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
you still think its a distro problem?
Previous Comments:
[2012-12-20 22:30:59] sandaq at gmail dot com
also tested on 3 different linux centos and 1 debian all with defined correct
value of pi in math.h, all gave the same wrong output.
[2012-12-20 22:17:08] sandaq at gmail dot com
My distro is centos and pi is defined in math.h as correct value:
3.1415926535897932384626433832795029L
This happens on winxp also
[2012-12-20 22:08:31] bj...@php.net
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821edit=1
Bug #63819 [Asn]: 5.4.10 package seems incomplete and non-functional
Edit report at https://bugs.php.net/bug.php?id=63819edit=1 ID: 63819 Updated by: szar...@php.net Reported by:spause at gmail dot com Summary:5.4.10 package seems incomplete and non-functional Status: Assigned Type: Bug Package:*General Issues Operating System: N/A PHP Version:5.4.10 Assigned To:szarkos Block user comment: N Private report: N New Comment: Hello! Thank you for submitting this bug report. We have completed our functional and performance tests on PHP 5.4.10 and verified that the download and build does work. I think the issue may lie elsewhere, perhaps with a configuration parameter. Can you please check the following: - The extension_dir parameter in php.ini (or check in phpinfo()) to make sure you are loading extensions from the correct PHP version. - If you are using the PHPRC FastCGI environment variable, please make sure this is also pointing to the correct PHP install and php.ini file. To explain further - In 5.4.8 we updated our ICU library deps to version 4.9 from 4.6. However, due to a bug in our build env we ended up copying some of the 4.6 DLLs into the final .zip package. Though to be clear we did not use them to build PHP nor were they loaded at runtime. You can see this in the 5.4.9 .zip for example (they are called icu*46.dll), but as I said they are superfluous and do not interfere with icu*49.dll files nor the functionality of PHP (which is why we didn't notice right away). In any case this was fixed in 5.4.10, and accounts for the change in .zip file size. My guess is that if one of the above parameters are set incorrectly then you may be loading an extension from an older version of 5.4 that require the icu*46 DLLs, but now that they're not there it may be causing issues. Hopefully if this is the case then it's an easy fix. If you find this is not the case then please provide more info regarding what errors you are seeing and what application(s) you are testing. If you don't see errors displayed you may try running PHP on the command-line to see if it prints out any errors or warnings. If possible, please also email me or post the output of phpinfo() as well. Thanks! Steve Previous Comments: [2012-12-20 17:38:43] spause at gmail dot com Description: Current windows package for php-5.4.10-nts-Win32-VC9-x86.zip appears to be incomplete. A standalone install of this package fails to work for at least one application that was able to function on 5.4.8. Only by merging the contents of this zip with 5.4.8 was I able to get the application to function. I suspect some files were accidentally left out of this 5.4.10 package. Please note the significant discrepancy in file sizes Affected file: http://windows.php.net/downloads/releases/php-5.4.10-nts-Win32-VC9-x86.zip File size: 16507699 Previous version: http://windows.php.net/downloads/releases/archives/php-5.4.9-nts-Win32-VC9-x86.zip File size: 23264651 -- Edit this bug report at https://bugs.php.net/bug.php?id=63819edit=1
Bug #63821 [Asn-Nab]: incorrect pi value
Edit report at https://bugs.php.net/bug.php?id=63821edit=1
ID: 63821
Updated by: cataphr...@php.net
Reported by:sandaq at gmail dot com
Summary:incorrect pi value
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:Math related
Operating System: linux
PHP Version:5.3.20
Assigned To:bjori
Block user comment: N
Private report: N
New Comment:
Nothing to see here, read about floating point numbers and their rounding error.
In[9]:= Pi \
//SetPrecision[#,MachinePrecision] \
//SetPrecision[#,Infinity] \
//N[#,100]
Out[9]= 3.141592653589793115997963468544185161590576171875000\
Previous Comments:
[2012-12-20 22:32:40] sandaq at gmail dot com
you still think its a distro problem?
[2012-12-20 22:30:59] sandaq at gmail dot com
also tested on 3 different linux centos and 1 debian all with defined correct
value of pi in math.h, all gave the same wrong output.
[2012-12-20 22:17:08] sandaq at gmail dot com
My distro is centos and pi is defined in math.h as correct value:
3.1415926535897932384626433832795029L
This happens on winxp also
[2012-12-20 22:08:31] bj...@php.net
You'll need to complain to whatever distribution you are using.
We don't define the value unless math.h doesn't define it for some wacky reason
on your platform, in which case we fallback on 3.14159265358979323846.
[2012-12-20 21:43:05] sandaq at gmail dot com
Description:
php doesn't calculate the correct value of pi
Test script:
---
php-cli -r 'ini_set('precision','100'); echo pi();'
or
?
ini_set('precision','100');
echo pi().\n; exit;
?
Expected result:
3.141592653589793238462643383279502884197169399375
Actual result:
--
3.141592653589793115997963468544185161590576171875
^
--
Edit this bug report at https://bugs.php.net/bug.php?id=63821edit=1
Req #63284 [Csd]: Please upgrade PCRE
Edit report at https://bugs.php.net/bug.php?id=63284edit=1 ID: 63284 User updated by:danielklein at airpost dot net Reported by:danielklein at airpost dot net Summary:Please upgrade PCRE Status: Closed Type: Feature/Change Request Package:PCRE related PHP Version:5.4.7 Assigned To:ab Block user comment: N Private report: N New Comment: Good news Nicolas! I'm assuming this will need another change request to make it into a future version of PHP. Previous Comments: [2012-12-20 14:07:23] nicolas dot grekas+php at gmail dot com Version 8.32 is out ! http://vcs.pcre.org/viewvc/code/tags/pcre-8.32/ [2012-10-19 08:34:14] a...@php.net Thanks for testing ) @danielklein Theoretically it can be done, depends how much of other things one has on the plate right now. If you're highly interested having the newest PCRE, monitor it and do requests - later or sooner they'll be taken on ) [2012-10-19 08:05:56] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=276c5de0d86abab52a19f489dd74565fdec0d3ca Log: Fixed bug #63284 PCRE upgrade to 8.31 [2012-10-19 01:32:42] mattfic...@php.net I built PHP_5_4 (newest snapshot) with your patch. I tested it with all the PHPTs (all, including the PCRE tests) and all the PHPUnit tests from Joomla and found no regressions. I got no additional test failures after I applied your patch. [2012-10-18 23:43:17] danielklein at airpost dot net Can the latest PCRE be included in PHP every time it's released? 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=63284 -- Edit this bug report at https://bugs.php.net/bug.php?id=63284edit=1
[PHP-BUG] Bug #63822 [NEW]: Zend/tests/bug54367.phpt segfaults
From: nikic Operating system: PHP version: 5.5.0alpha2 Package: Scripting Engine problem Bug Type: Bug Bug description:Zend/tests/bug54367.phpt segfaults Description: The test Zend/tests/bug54367.phpt segfaults for me and throws invalid reads on gcov: http://gcov.php.net/viewer.php?version=PHP_5_5func=valgrindfile=Zend%2Ftests%2Fbug54367.phpt The closure op_array is freed too early. -- Edit bug report at https://bugs.php.net/bug.php?id=63822edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63822r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63822r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63822r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63822r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63822r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63822r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63822r=needscript Try newer version: https://bugs.php.net/fix.php?id=63822r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63822r=support Expected behavior: https://bugs.php.net/fix.php?id=63822r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63822r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63822r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63822r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63822r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63822r=dst IIS Stability: https://bugs.php.net/fix.php?id=63822r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63822r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63822r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63822r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63822r=mysqlcfg
Bug #63822 [Opn-Csd]: Zend/tests/bug54367.phpt segfaults
Edit report at https://bugs.php.net/bug.php?id=63822edit=1 ID: 63822 Updated by: ni...@php.net Reported by:ni...@php.net Summary:Zend/tests/bug54367.phpt segfaults -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.5.0alpha2 Block user comment: N Private report: N New Comment: Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=ffb848b275a085917413c171a79cbfdb1d0159d2 Log: Fix bug #63822: Crash when using closures with ArrayAccess Previous Comments: [2012-12-21 00:46:50] ni...@php.net Description: The test Zend/tests/bug54367.phpt segfaults for me and throws invalid reads on gcov: http://gcov.php.net/viewer.php?version=PHP_5_5func=valgrindfile=Zend%2Ftests%2Fbug54367.phpt The closure op_array is freed too early. -- Edit this bug report at https://bugs.php.net/bug.php?id=63822edit=1
[PHP-BUG] Bug #63823 [NEW]: SPL InfiniteIterator needs explicit rewind to be usable in a closure
From: sixd
Operating system: Linux
PHP version: 5.4Git-2012-12-21 (Git)
Package: SPL related
Bug Type: Bug
Bug description:SPL InfiniteIterator needs explicit rewind to be usable in a
closure
Description:
SPL's InfiniteIterator returns NULL for the first access, unless used in a
'foreach' loop, or a rewind is done.
This means that an explicit rewind is needed before an InfiniteIterator can
be
safely be used in an application.
Test script:
---
?php
$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i 7; $i++) {
var_dump($b_it-current());
$b_it-next();
}
?
Expected result:
string(3) one
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
Actual result:
--
NULL
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
--
Edit bug report at https://bugs.php.net/bug.php?id=63823edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63823r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63823r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63823r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63823r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63823r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63823r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63823r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63823r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63823r=support
Expected behavior: https://bugs.php.net/fix.php?id=63823r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63823r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63823r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63823r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63823r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63823r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63823r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63823r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63823r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63823r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63823r=mysqlcfg
Bug #63823 [Opn]: SPL InfiniteIterator needs explicit rewind to be usable in a closure
Edit report at https://bugs.php.net/bug.php?id=63823edit=1
ID: 63823
Updated by: s...@php.net
Reported by:s...@php.net
Summary:SPL InfiniteIterator needs explicit rewind to be
usable in a closure
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.4Git-2012-12-21 (Git)
Block user comment: N
Private report: N
New Comment:
A bigger example is:
?php
echo 'foreach' on ArrayIterator\n;
$c = array('one', 'two', 'three');
$c_it = new ArrayIterator($c);
foreach ($c_it as $key = $val) {
var_dump($val);
}
echo \n'foreach' on InfiniteIterator\n;
$a = array('one', 'two', 'three');
$a_it = new InfiniteIterator(new ArrayIterator($a));
$i = 0;
foreach ($a_it as $key = $val) {
if ($i++ = 7) break;
var_dump($val);
}
echo \n'for' on ArrayIterator\n;
$d = array('one', 'two', 'three');
$d_it = new ArrayIterator($d);
for ($i = 0; $i 3; $i++) {
var_dump($d_it-current());
$d_it-next();
}
echo \n'for' on InfiniteIterator\n;
$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i 7; $i++) {
var_dump($b_it-current());
$b_it-next();
}
?
This outputs:
'foreach' on ArrayIterator
string(3) one
string(3) two
string(5) three
'foreach' on InfiniteIterator
string(3) one
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
'for' on ArrayIterator
string(3) one
string(3) two
string(5) three
'for' on InfiniteIterator
NULL
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
So the odd behavior is with the last loop.
A real life script (from discussion on php.internals) is:
?php
// Replacing words in a string with a sequential, repeating set of replacement
words
$replacements = array('one', 'two', 'three');
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word'
);
var_dump($result);
// Outputs:
//string(21) one two three one two
// Without the call to $replacements_iterator-rewind(), the output is:
//string(18) two three one two
?
Previous Comments:
[2012-12-21 02:17:17] s...@php.net
Description:
SPL's InfiniteIterator returns NULL for the first access, unless used in a
'foreach' loop, or a rewind is done.
This means that an explicit rewind is needed before an InfiniteIterator can be
safely be used in an application.
Test script:
---
?php
$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i 7; $i++) {
var_dump($b_it-current());
$b_it-next();
}
?
Expected result:
string(3) one
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
Actual result:
--
NULL
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
--
Edit this bug report at https://bugs.php.net/bug.php?id=63823edit=1
Bug #63823 [Opn]: SPL InfiniteIterator needs explicit rewind to be usable in a closure
Edit report at https://bugs.php.net/bug.php?id=63823edit=1
ID: 63823
Updated by: larue...@php.net
Reported by:s...@php.net
Summary:SPL InfiniteIterator needs explicit rewind to be
usable in a closure
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux
PHP Version:5.4Git-2012-12-21 (Git)
Block user comment: N
Private report: N
New Comment:
I saw similar report before, and remembered someone mark it as won't fix.. I
just
can not find the previous report now...
Previous Comments:
[2012-12-21 02:20:57] s...@php.net
A bigger example is:
?php
echo 'foreach' on ArrayIterator\n;
$c = array('one', 'two', 'three');
$c_it = new ArrayIterator($c);
foreach ($c_it as $key = $val) {
var_dump($val);
}
echo \n'foreach' on InfiniteIterator\n;
$a = array('one', 'two', 'three');
$a_it = new InfiniteIterator(new ArrayIterator($a));
$i = 0;
foreach ($a_it as $key = $val) {
if ($i++ = 7) break;
var_dump($val);
}
echo \n'for' on ArrayIterator\n;
$d = array('one', 'two', 'three');
$d_it = new ArrayIterator($d);
for ($i = 0; $i 3; $i++) {
var_dump($d_it-current());
$d_it-next();
}
echo \n'for' on InfiniteIterator\n;
$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i 7; $i++) {
var_dump($b_it-current());
$b_it-next();
}
?
This outputs:
'foreach' on ArrayIterator
string(3) one
string(3) two
string(5) three
'foreach' on InfiniteIterator
string(3) one
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
'for' on ArrayIterator
string(3) one
string(3) two
string(5) three
'for' on InfiniteIterator
NULL
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
So the odd behavior is with the last loop.
A real life script (from discussion on php.internals) is:
?php
// Replacing words in a string with a sequential, repeating set of replacement
words
$replacements = array('one', 'two', 'three');
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word'
);
var_dump($result);
// Outputs:
//string(21) one two three one two
// Without the call to $replacements_iterator-rewind(), the output is:
//string(18) two three one two
?
[2012-12-21 02:17:17] s...@php.net
Description:
SPL's InfiniteIterator returns NULL for the first access, unless used in a
'foreach' loop, or a rewind is done.
This means that an explicit rewind is needed before an InfiniteIterator can be
safely be used in an application.
Test script:
---
?php
$b = array('one', 'two', 'three');
$b_it = new InfiniteIterator(new ArrayIterator($b));
for ($i = 0; $i 7; $i++) {
var_dump($b_it-current());
$b_it-next();
}
?
Expected result:
string(3) one
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
Actual result:
--
NULL
string(3) two
string(5) three
string(3) one
string(3) two
string(5) three
string(3) one
--
Edit this bug report at https://bugs.php.net/bug.php?id=63823edit=1
Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)
Edit report at https://bugs.php.net/bug.php?id=61045edit=1 ID: 61045 Comment by: services at ilboo dot com Reported by:lxlight at gmail dot com Summary:fpm don't send error log to fastcgi clients(nginx) Status: Closed Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.10 Assigned To:fat Block user comment: N Private report: N New Comment: For those of you on Ubuntu Precise and wanting this bug to be fixed in an update, please subscribe to this bug in Launchpad and click This bug affects me. This will raise the Bug Heat score giving the bug more attention. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/69 Previous Comments: [2012-09-12 04:09:55] larue...@php.net you can patch that patch your self.. if you really want to insist to 5.3.10 [2012-09-11 22:07:11] ryan dot pendergast at gmail dot com Is there a work around for us that are stuck on 5.3.10? [2012-06-15 06:00:41] f...@php.net yes this fix will go live in the next 5.3 and 5.4 release. [2012-06-15 05:25:40] hb at peytz dot dk Any news about when this will see a release? Maybe 5.3.15 ? 5.4.5? [2012-05-22 17:46:33] arohter at gmail dot com Does this mean the fix will go live in the official 5.3.14 release? 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=61045 -- Edit this bug report at https://bugs.php.net/bug.php?id=61045edit=1
[PHP-BUG] Bug #63825 [NEW]: php dose not follow the operator precedence
From: rssidea at qq dot com
Operating system: all
PHP version: 5.3.20
Package: *Compile Issues
Bug Type: Bug
Bug description:php dose not follow the operator precedence
Description:
By Operator Precedence on
http://php.net/manual/en/language.operators.precedence.php, logical
operator '||'
is higher than assignment operator '=', so the script below should cause a
syntax
error.
Test script:
---
$a = $b = 0;
if ($a = 1 || $b = 1) {
echo $a;
}
Expected result:
execute as:
if ($a = (1 || $b) = 1) {
output:
syntax error, unexpected '='
Actual result:
--
execute as:
if ($a = (1 || ($b = 1))) {
output:
1
--
Edit bug report at https://bugs.php.net/bug.php?id=63825edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63825r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63825r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63825r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63825r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63825r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63825r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63825r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63825r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63825r=support
Expected behavior: https://bugs.php.net/fix.php?id=63825r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63825r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63825r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63825r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63825r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63825r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63825r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63825r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63825r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63825r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63825r=mysqlcfg
Bug #63825 [Opn-Csd]: php dose not follow the operator precedence
Edit report at https://bugs.php.net/bug.php?id=63825edit=1
ID: 63825
User updated by:rssidea at qq dot com
Reported by:rssidea at qq dot com
Summary:php dose not follow the operator precedence
-Status: Open
+Status: Closed
Type: Bug
Package:*Compile Issues
Operating System: all
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
I find a note in documentation:Although = has a lower precedence than most
other
operators, PHP will still allow expressions similar to the following: if (!$a =
foo()), in which case the return value of foo() is put into $a.
so, this is not a bug, but it may be a snare :)
Previous Comments:
[2012-12-21 06:10:55] rssidea at qq dot com
Description:
By Operator Precedence on
http://php.net/manual/en/language.operators.precedence.php, logical operator
'||'
is higher than assignment operator '=', so the script below should cause a
syntax
error.
Test script:
---
$a = $b = 0;
if ($a = 1 || $b = 1) {
echo $a;
}
Expected result:
execute as:
if ($a = (1 || $b) = 1) {
output:
syntax error, unexpected '='
Actual result:
--
execute as:
if ($a = (1 || ($b = 1))) {
output:
1
--
Edit this bug report at https://bugs.php.net/bug.php?id=63825edit=1
