Req #63728 [Opn->Dup]: 64 bits Windows binaries
Edit report at https://bugs.php.net/bug.php?id=63728&edit=1 ID: 63728 Updated by: paj...@php.net Reported by:otomatic at otomatic dot net Summary:64 bits Windows binaries -Status: Open +Status: Duplicate Type: Feature/Change Request Package:Windows Installer Operating System: Windows 7 PHP Version:5.4.9 Block user comment: N Private report: N New Comment: There is already a feature request for 64bit binaries. 5.5 may have again experimental 64bits build but not earlier releases. Previous Comments: [2012-12-08 18:23:50] otomatic at otomatic dot net Description: Hi, In the same way that it is for Apache (apachelounge) and MySQL, is it possible to have Windows binaries compiled 64-bit? Thank you. -- Edit this bug report at https://bugs.php.net/bug.php?id=63728&edit=1
Bug #63729 [Fbk->Opn]: E_DEPRECATED errors is not handled properly
Edit report at https://bugs.php.net/bug.php?id=63729&edit=1 ID: 63729 User updated by:dinoel at gmail dot com Reported by:dinoel at gmail dot com Summary:E_DEPRECATED errors is not handled properly -Status: Feedback +Status: Open Type: Bug Package:Scripting Engine problem Operating System: windows PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Hi, Yes, if you run testfile.php then error error reporting setting takes effect, but if you run testfile1.php then it does not. Please run testfile1.php (as explained in description) and you will see what i mean. This is clean install and no opcode caches/debug extensions been loaded. Previous Comments: [2012-12-10 02:22:27] ahar...@php.net I can't reproduce this on 5.3 or 5.4: as expected, if I run testfile.php, the error reporting setting takes effect and hides the deprecation warning in the included file. What extensions do you have loaded? In particular, opcode caches and debugging extensions like xdebug and scream would be interesting, but a full list would be good. [2012-12-08 20:34:38] dinoel at gmail dot com Happens on 5.3.19 also. [2012-12-08 20:32:22] dinoel at gmail dot com Description: Hi, E_DEPRECATED is not handled properly if error handler / error reporting is set in same file. pre-requirements : error_reporting set to E_ALL in php.ini file I assume this is because E_DEPRECATED error is fired on "compile" time, not execution time.. Please notice that this problem happens only with " =& new ..." constructions (and probably some others) , other kind of E_DEPRECATED errors (like one which fired when i'm using deprecated functions, like ereg) are handled as expected. This bug is probably related : https://bugs.php.net/bug.php?id=61031 Test script: --- testfile.php testfile1.php Expected result: php -f testfile.php success php -f testfile1.php success Actual result: -- php -f testfile.php "success" php -f testfile1.php PHP Deprecated: Assigning the return value of new by reference is deprecated in testfile1.php on line 6 Deprecated: Assigning the return value of new by reference is deprecated in testfile1.php on line 6 success -- Edit this bug report at https://bugs.php.net/bug.php?id=63729&edit=1
Bug #63729 [Opn->Nab]: E_DEPRECATED errors is not handled properly
Edit report at https://bugs.php.net/bug.php?id=63729&edit=1 ID: 63729 Updated by: ahar...@php.net Reported by:dinoel at gmail dot com Summary:E_DEPRECATED errors is not handled properly -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: windows PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Ah, I see. I didn't get that from your original post, sorry. You are correct that certain E_DEPRECATED errors, such as assigning the return value of new by reference, occur at compile time, and hence before an error_reporting() call can take effect. This is expected behaviour â to control which compile errors are shown, you need to edit php.ini. Not a bug â closing. Previous Comments: [2012-12-10 10:19:18] dinoel at gmail dot com Hi, Yes, if you run testfile.php then error error reporting setting takes effect, but if you run testfile1.php then it does not. Please run testfile1.php (as explained in description) and you will see what i mean. This is clean install and no opcode caches/debug extensions been loaded. [2012-12-10 02:22:27] ahar...@php.net I can't reproduce this on 5.3 or 5.4: as expected, if I run testfile.php, the error reporting setting takes effect and hides the deprecation warning in the included file. What extensions do you have loaded? In particular, opcode caches and debugging extensions like xdebug and scream would be interesting, but a full list would be good. [2012-12-08 20:34:38] dinoel at gmail dot com Happens on 5.3.19 also. [2012-12-08 20:32:22] dinoel at gmail dot com Description: Hi, E_DEPRECATED is not handled properly if error handler / error reporting is set in same file. pre-requirements : error_reporting set to E_ALL in php.ini file I assume this is because E_DEPRECATED error is fired on "compile" time, not execution time.. Please notice that this problem happens only with " =& new ..." constructions (and probably some others) , other kind of E_DEPRECATED errors (like one which fired when i'm using deprecated functions, like ereg) are handled as expected. This bug is probably related : https://bugs.php.net/bug.php?id=61031 Test script: --- testfile.php testfile1.php Expected result: php -f testfile.php success php -f testfile1.php success Actual result: -- php -f testfile.php "success" php -f testfile1.php PHP Deprecated: Assigning the return value of new by reference is deprecated in testfile1.php on line 6 Deprecated: Assigning the return value of new by reference is deprecated in testfile1.php on line 6 success -- Edit this bug report at https://bugs.php.net/bug.php?id=63729&edit=1
Bug #63726 [Asn]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Updated by: m...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:dmitry Block user comment: N Private report: N New Comment: Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) [2012-12-09 13:20:05] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 [2012-12-09 13:08:38] larue...@php.net dmitry, could you review this patch please? thanks [2012-12-09 13:07:37] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355058457 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355058457 [2012-12-09 12:32:48] larue...@php.net compiled successfully, and reproduced this problem now :) 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63726 [Asn]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Updated by: dmi...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant -Assigned To:dmitry +Assigned To:laruence Block user comment: N Private report: N New Comment: The patch looks good. Please commit it into 5.3 and above. Previous Comments: [2012-12-10 10:58:05] m...@php.net Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) [2012-12-09 13:20:05] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 [2012-12-09 13:08:38] larue...@php.net dmitry, could you review this patch please? thanks [2012-12-09 13:07:37] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355058457 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355058457 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63726 [PATCH]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Patch added by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355139037 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355139037 Previous Comments: [2012-12-10 11:11:55] dmi...@php.net The patch looks good. Please commit it into 5.3 and above. [2012-12-10 10:58:05] m...@php.net Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) [2012-12-09 13:20:05] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 [2012-12-09 13:08:38] larue...@php.net dmitry, could you review this patch please? 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #31398 [Com]: File Upload Original name problem with magic_quotes_gpc = On
Edit report at https://bugs.php.net/bug.php?id=31398&edit=1 ID: 31398 Comment by: jpowell at formability dot co dot uk Reported by:lobo235 at gmail dot com Summary:File Upload Original name problem with magic_quotes_gpc = On Status: Closed Type: Bug Package:*Web Server problem Operating System: Windows and Linux PHP Version:4CVS-2005-01-04 (stable) Block user comment: N Private report: N New Comment: This is still an issue on version 5.3.13 with magic_quotes_gpc turned on using Wamp v2. Previous Comments: [2011-07-19 00:51:22] ecolora at gmail dot com See here how to correct the problem: http://ecolora.ru/index.php/2010-07-09-03-51-16/veb-dizajn-i-programmirovanie/868-kak-iz-files-poluchit-celoe-imja-fajla-s-kavychkoj [2005-01-20 18:57:46] il...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-01-11 13:03:40] fsolinas at it dot tiscali dot com I've been able to reproduce this bug on PHP 4.3.10 with magic_quotes_gpc = On. It's *not* reproducible turning off magic_quotes_gpc, because the array element containing the (original) file name is preserved "intact" this way. This bug seems to have been introduced in 4.3.10, and breaks many document management systems that rely on $_FILES['userfile']['name'] as the name of the file uploaded, definitely forcing users to *not* use single quotes in filename. Do you plan to write a patch to fix this behaviour? [2005-01-05 16:18:51] lobo235 at gmail dot com It may be only PHP4 specific, I do remember it working at one point though using PHP4 a couple of months ago. I had written a file upload script for one of my sites and I remember testing to see what types of filenames it would support and the apostrophes worked fine then. It wasn't until just recently that my host upgraded to 4.3.10 that I started to notice the problem, now my script does not work as it used to. [2005-01-05 10:11:50] vr...@php.net I can't reproduce this on PHP 5.0.2 with php.ini-dist, Apache 2 and Windows. "lobo235's fam.jpg" becomes "lobo235\'s fam.jpg" or "lobo235's fam.jpg" with magic_quotes_gpc=Off. Maybe it's PHP 4 specific. 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=31398 -- Edit this bug report at https://bugs.php.net/bug.php?id=31398&edit=1
Bug #63726 [Asn]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Updated by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: @mike according your new comment, I updated the patch. it should only occurred in zts version. Previous Comments: [2012-12-10 11:30:37] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355139037 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355139037 [2012-12-10 11:11:55] dmi...@php.net The patch looks good. Please commit it into 5.3 and above. [2012-12-10 10:58:05] m...@php.net Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) [2012-12-09 13:20:05] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63726 [Asn->Csd]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Updated by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=ad553a7af237818f5d7690e97a03ffe66ec9ab37 Log: Fixed bug #63726 (Memleak with static properties and internal/user classes) Previous Comments: [2012-12-10 11:32:15] larue...@php.net @mike according your new comment, I updated the patch. it should only occurred in zts version. [2012-12-10 11:30:37] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355139037 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355139037 [2012-12-10 11:11:55] dmi...@php.net The patch looks good. Please commit it into 5.3 and above. [2012-12-10 10:58:05] m...@php.net Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
[PHP-BUG] Bug #63736 [NEW]: array_key_exists extremely slow on referenced arrays
From: ymgve dot aa at gmail dot com Operating system: Windows PHP version: 5.4.9 Package: Performance problem Bug Type: Bug Bug description:array_key_exists extremely slow on referenced arrays Description: When you use array_key_exists() on a referenced array, it performs extremely slow compared to isset(): isset time 0.0053699016571045 size 0 isset time 0.0051219463348389 size 10 isset time 0.0032069683074951 size 100 isset time 0.0034000873565674 size 1000 isset time 0.0052909851074219 size 1 array_key_exists time 0.0055620670318604 size 0 array_key_exists time 0.010941982269287 size 10 array_key_exists time 0.048230886459351 size 100 array_key_exists time 0.38906383514404 size 1000 array_key_exists time 5.6351599693298 size 1 Due to the time increasing near linearly with the number of elements in the array, I assume the code for some reason looks through the array key linearly instead of using a hash lookup. Test script: --- http://pastebin.com/PVrf96an -- Edit bug report at https://bugs.php.net/bug.php?id=63736&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63736&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63736&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63736&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63736&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63736&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63736&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63736&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63736&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63736&r=support Expected behavior: https://bugs.php.net/fix.php?id=63736&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63736&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63736&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63736&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63736&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63736&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63736&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63736&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63736&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63736&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63736&r=mysqlcfg
Bug #63736 [Opn->Nab]: array_key_exists extremely slow on referenced arrays
Edit report at https://bugs.php.net/bug.php?id=63736&edit=1 ID: 63736 Updated by: johan...@php.net Reported by:ymgve dot aa at gmail dot com Summary:array_key_exists extremely slow on referenced arrays -Status: Open +Status: Not a bug Type: Bug Package:Performance problem Operating System: Windows PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php References disable copy-on-write. http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html has some details Previous Comments: [2012-12-10 13:39:31] ymgve dot aa at gmail dot com Description: When you use array_key_exists() on a referenced array, it performs extremely slow compared to isset(): isset time 0.0053699016571045 size 0 isset time 0.0051219463348389 size 10 isset time 0.0032069683074951 size 100 isset time 0.0034000873565674 size 1000 isset time 0.0052909851074219 size 1 array_key_exists time 0.0055620670318604 size 0 array_key_exists time 0.010941982269287 size 10 array_key_exists time 0.048230886459351 size 100 array_key_exists time 0.38906383514404 size 1000 array_key_exists time 5.6351599693298 size 1 Due to the time increasing near linearly with the number of elements in the array, I assume the code for some reason looks through the array key linearly instead of using a hash lookup. Test script: --- http://pastebin.com/PVrf96an -- Edit this bug report at https://bugs.php.net/bug.php?id=63736&edit=1
