Req #60703 [Com]: support for reference cursors on pdo_oci
Edit report at https://bugs.php.net/bug.php?id=60703&edit=1 ID: 60703 Comment by: gureedo at gmail dot com Reported by:marcos dot ramirez dot aranda at gmail dot com Summary:support for reference cursors on pdo_oci Status: Open Type: Feature/Change Request Package:PDO related Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: attatched patch does not work with ZTS enabled configuration. Previous Comments: [2012-01-10 19:55:18] marcos dot ramirez dot aranda at gmail dot com Description: PDO_OCI doesn't yet allow fetching ref cursors with oracle (or any other database). This patch adds support for fetching reference cursors on pdo_oci on both SELECT's as well CALL's to stored procedures (see the example below). Test script: --- $dbh = new PDO('oci:dbname=//localhost/XE', 'user', 'pass'); $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING); $sql = "select cursor(select table_name, owner from all_tables where rownum <= 1) as cursor from dual"; $sth = $dbh->prepare($sql); $sth->execute(); $row = $sth->fetch(PDO::FETCH_ASSOC); var_dump($row); if (is_a($row['CURSOR'],'PDOStatement')) { $sthc = $row['CURSOR']; while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) { var_dump($rr); } } $sql = "begin OPEN :c FOR 'SELECT table_name FROM all_TABLES WHERE ROWNUM <= 1'; END;"; $sthc = ''; $sth = $dbh->prepare($sql); $sth->bindParam(":c", $sthc, PDO::PARAM_STMT|PDO::PARAM_INPUT_OUTPUT); $sth->execute(); if ($sthc && is_a($sthc,'PDOStatement')) while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) { var_dump($rr); } Expected result: array(1) { ["CURSOR"]=> object(PDOStatement)#3 (1) { ["queryString"]=> NULL } } array(2) { ["TABLE_NAME"]=> string(5) "ICOL$" ["OWNER"]=> string(3) "SYS" } array(1) { ["TABLE_NAME"]=> string(5) "ICOL$" } Actual result: -- PHP Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932 OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932 OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD bool(false) PHP Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008 OCIStmtExecute: ORA-01008: not all variables bound Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008 OCIStmtExecute: ORA-01008: not all variables bound -- Edit this bug report at https://bugs.php.net/bug.php?id=60703&edit=1
Bug #50768 [Com]: SoapClient parsing error on complex types
Edit report at https://bugs.php.net/bug.php?id=50768&edit=1 ID: 50768 Comment by: pkmishra at gmail dot com Reported by:alrik dot zachert at erento dot com Summary:SoapClient parsing error on complex types Status: Open Type: Bug Package:SOAP related Operating System: Ubuntu 9.04 PHP Version:5.3.1 Block user comment: N Private report: N New Comment: Same problem on mac MAMP - PHP 5.3.6. Previous Comments: [2011-05-06 16:23:14] m dot breiner at brinell dot net I'm experiencing a similar issue on PHP 5.3.6: If a SOAP message refers to a complexType that is comprised of an xsd:all, PHP's SOAP implementation seems to require _all_ of the xsd:all's elements (which is not the idea of an xsd:all). I.e., when using e.g. a classmap, if such an element is not declared as a property, a SOAP error is thrown: SOAP-ERROR: Encoding: object has no 'foo' property in... [2010-01-15 14:54:39] alrik dot zachert at erento dot com Description: the native php soapclient throws a soapfault when passing complex types to a soap-service on php5.3.1 whereas php5.2.6-soapclient works correctly. both, 5.3.1 and 5.2.6 ran on same machine with same modules enabled and almost same config. the soapserver provides a test method that accepts exactly one parameter of type TestUser (see below) and returns the modified test object. I've tested the soapserver with soapUI and checked the wdsl, it 100%ly valid. But the client on php5.3.1 troubles. See the actual soap-request (php5.3.1 vs. php5.2.6) below. I guess it's a parsing error, but i couldn't find any hint in the releasenotes and changelogs. You can also reproduce the bug??? by using Zend_Soap_Client, since it uses the native one. Reproduce code: --- array ( 'TestUser' => 'TestUser' ) )); var_dump( $sc->test($objUser) ); ?> intUserId = 123456789; $objUser->strName = 'somename'; return $objUser; } ?> the wsdl: ==> http://schemas.xmlsoap.org/wsdl/"; xmlns:tns="urn:SoaptestControllerwsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"; name="SoaptestController" targetNamespace="urn:SoaptestControllerwsdl"> http://schemas.xmlsoap.org/soap/http"/> http://schemas.xmlsoap.org/soap/encoding/"/> http://schemas.xmlsoap.org/soap/encoding/"/> http://localhost:81/yii/fTest/index.php/soaptest/test/ws/1"/> Expected result: the expacted service result: object(TestUser)#3 (2) { ["intUserId"]=> int(123456789) ["strName"]=> string(8) "somename" } the expacted client-request : .. ... Actual result: -- php5.3.1 => Fatal error: Uncaught SoapFault exception: [Client] looks like we got no XML document in /home/alrik/-:13 Stack trace: #0 [internal function]: SoapClient->__call('test', Array) #1 /home/alrik/-(13): SoapClient->test(Object(TestUser)) #2 {main} thrown in /home/alrik/- on line 13 php5.2.6 service result => object(TestUser)#3 (2) { ["intUserId"]=> int(123456789) ["strName"]=> string(8) "somename" } php5.3.1 client-request : -- Edit this bug report at https://bugs.php.net/bug.php?id=50768&edit=1
Bug #61423 [Csd->Asn]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423&edit=1 ID: 61423 User updated by:borrible13th at gmx dot net Reported by:borrible13th at gmx dot net Summary:gzip compression fails -Status: Closed +Status: Assigned Type: Bug Package:SOAP related Operating System: ALL PHP Version:5.4.0 Assigned To:iliaa Block user comment: N Private report: N New Comment: Changed status to "Assigned" due to last comment. Previous Comments: [2012-03-19 12:36:54] borrible13th at gmx dot net Can't see a bugfix in the source code whether in the branch for 5.4 or in the trunk! The magic number (1) is still hard coded. Do I miss something? [2012-03-18 15:15:47] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-17 02:01:29] borrible13th at gmx dot net Description: SOAP fails to compress with gzip encoding (compression level greater 0): it warns "encoding mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or ZLIB_ENCODING_DEFLATE" and throws SoapFault with "SoapClient::__doRequest() returned non string value". Cause: Zlib introduces new constants ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP, ZLIB_ENCODING_DEFLATE and redefines FORCE_GZIP as ZLIB_ENCODING_GZIP and FORCE_DEFLATE as ZLIB_ENCODING_DEFLATE. In php_http.c, line 263ff. the call to gzencode is prepared with an hard coded magic number (1) for the gzip encoding: gzencode(data, level, 1). It should be gzencode(data, level, FORCE_GZIP) or gzencode(data, level, ZLIB_ENCODING_GZIP), because the magic number is now defined as 0x1f (31). Test script: --- new SoapClient($wsdl, array('soap_version' => SOAP_1_2, 'compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | 1 )); Expected result: Call gzencode(data, level, FORCE_GZIP) (or gzencode(data, level, ZLIB_ENCODING_GZIP)), so it returns compressed data. Actual result: -- gzencode(data, level, 1) is called, so it returns always false and warns "encoding mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or ZLIB_ENCODING_DEFLATE". -- Edit this bug report at https://bugs.php.net/bug.php?id=61423&edit=1
[PHP-BUG] Bug #61446 [NEW]: Can't prepare statement without getting a result
From: Operating system: ubuntu 11.04 PHP version: 5.3.10 Package: MySQLi related Bug Type: Bug Bug description:Can't prepare statement without getting a result Description: --- >From manual page: http://www.php.net/mysqli.prepare --- There are an error if I heven't got a result from statement. Just execute the script with and without commented string. And there are no description in the documentation. Test script: --- prepare("SELECT 1"); $st->execute(); // print_r($st->get_result()->fetch_assoc()); $st = $mysqli->prepare("SELECT 2"); $st->execute(); ?> Actual result: -- Fatal error: Call to a member function execute() on a non-objec -- Edit bug report at https://bugs.php.net/bug.php?id=61446&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61446&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61446&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61446&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61446&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61446&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61446&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61446&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61446&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61446&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61446&r=support Expected behavior: https://bugs.php.net/fix.php?id=61446&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61446&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61446&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61446&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61446&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61446&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61446&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61446&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61446&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61446&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61446&r=mysqlcfg
Req #60742 [Asn->Csd]: FilesystemIterator::OTHER_MODE_MASK
Edit report at https://bugs.php.net/bug.php?id=60742&edit=1 ID: 60742 Updated by: johan...@php.net Reported by:jthijssen at noxlogic dot nl Summary:FilesystemIterator::OTHER_MODE_MASK -Status: Assigned +Status: Closed Type: Feature/Change Request Package:SPL related PHP Version:5.4.0RC5 -Assigned To:colder +Assigned To:dsp Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. (sorry for the outdated message above ;-) ) Previous Comments: [2012-03-19 21:39:38] jthijssen at noxlogic dot nl Pull request merged by dsp_ into the git 5.4 branch: https://github.com/php/php-src/pull/5 [2012-01-13 12:44:46] jthijssen at noxlogic dot nl Description: The FileSystemIterator defines a few constants to mask its flags: CURRENT_MODE_MASK and KEY_MODE_MASK. However, there are other flags (SKIP_DOTS and UNIX_PATHS) which cannot be masked of by a constant. However, internally, there is a mask constant defined (SPL_FILE_DIR_OTHERS_MASK). It makes sense that this value is also known in PHP userland by the OTHER_MODE_MASK constant. The attached patch adds this constant and is compatible with trunk, php_5_4 and php_5_3 branches. Test script: --- getFlags() & FileSystemIterator::OTHER_MODE_MASK); print $masked_flags; Expected result: 4096 Actual result: -- PHP Notice: Use of undefined constant OTHER_MODE_MASK - assumed 'OTHER_MODE_MASK' -- Edit this bug report at https://bugs.php.net/bug.php?id=60742&edit=1
Req #60742 [Com]: FilesystemIterator::OTHER_MODE_MASK
Edit report at https://bugs.php.net/bug.php?id=60742&edit=1 ID: 60742 Comment by: jthijssen at noxlogic dot nl Reported by:jthijssen at noxlogic dot nl Summary:FilesystemIterator::OTHER_MODE_MASK Status: Assigned Type: Feature/Change Request Package:SPL related PHP Version:5.4.0RC5 Assigned To:colder Block user comment: N Private report: N New Comment: Pull request merged by dsp_ into the git 5.4 branch: https://github.com/php/php-src/pull/5 Previous Comments: [2012-01-13 12:44:46] jthijssen at noxlogic dot nl Description: The FileSystemIterator defines a few constants to mask its flags: CURRENT_MODE_MASK and KEY_MODE_MASK. However, there are other flags (SKIP_DOTS and UNIX_PATHS) which cannot be masked of by a constant. However, internally, there is a mask constant defined (SPL_FILE_DIR_OTHERS_MASK). It makes sense that this value is also known in PHP userland by the OTHER_MODE_MASK constant. The attached patch adds this constant and is compatible with trunk, php_5_4 and php_5_3 branches. Test script: --- getFlags() & FileSystemIterator::OTHER_MODE_MASK); print $masked_flags; Expected result: 4096 Actual result: -- PHP Notice: Use of undefined constant OTHER_MODE_MASK - assumed 'OTHER_MODE_MASK' -- Edit this bug report at https://bugs.php.net/bug.php?id=60742&edit=1
Bug #54384 [Com]: Several SPL classes crash when parent constructor is not called
Edit report at https://bugs.php.net/bug.php?id=54384&edit=1 ID: 54384 Comment by: maciej dot sz at gmail dot com Reported by:lbarn...@php.net Summary:Several SPL classes crash when parent constructor is not called Status: Closed Type: Bug Package:SPL related PHP Version:trunk-SVN-2011-03-25 (SVN) Assigned To:cataphract Block user comment: N Private report: N New Comment: This bug is still present in 5.4.0 Should I report this as separate bug? Previous Comments: [2011-10-29 23:17:14] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=318566 Log: - Reverted changes that required constructor overrides to invoke the parent constructor in several SPL classes and applied 5.3 fixes instead. Related bugs: #54384, #55175 and #55300 [2011-04-04 04:51:15] cataphr...@php.net Commited (different) fix in 5.3. [2011-04-04 04:50:30] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=309929 Log: - Fixed bug #54384 (Dual iterators, GlobIterator, SplFileObject and SplTempFileObject crash when user-space classes don't call the paren constructor). [2011-03-28 00:44:36] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=309751 Log: - Improved upon r309729. - Extented strategy to remaining the classes on spl_directory.c, even those that don't crash. - UPGRADING. - Better bug54384.phpt, with all the classes covered. [2011-03-27 06:21:09] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=309729 Log: - Fixed bug #54384: Several SPL classes crash when parent constructor is not called. #Merge to 5.3 pending (slight BC break on AppendIterator, as it's no #longer possible to defer the call to the parent constructor until #after the constructor is performed). #Bugs fixed in an atypical way for SPL. The parent constructor call #check is performed at construction time by using a wrapper constructor #instead of a check on the beginning of each instance method. #Perhaps this should be uniformized in trunk; this method was mainly #applied only to the ones crashing, except a few iterators (at least #AppendIterator and RecursiveIteratorIterator). 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=54384 -- Edit this bug report at https://bugs.php.net/bug.php?id=54384&edit=1
Bug #61443 [Opn->Fbk]: Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly.
Edit report at https://bugs.php.net/bug.php?id=61443&edit=1 ID: 61443 Updated by: m...@php.net Reported by:debian at ange7 dot com Summary:Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly. -Status: Open +Status: Feedback Type: Bug Package:PHP options/info functions Operating System: Debian Sid PHP Version:5.4.0 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Cannot reproduce. Are you sure about your reproduce script? Previous Comments: [2012-03-19 19:48:59] debian at ange7 dot com Description: Package: php5 Version: 5.4.0-2 Severity: important Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly. Test script: --- Expected result: end Actual result: -- Warning: ini_set(): Cannot enable zlib.output_compression - there has already been output in /home/alex/workspace/test/www/nouveauScript.php on line 3 end -- Edit this bug report at https://bugs.php.net/bug.php?id=61443&edit=1
Bug #55701 [Com]: GlobIterator throws LogicException with message 'The parent constructor was not
Edit report at https://bugs.php.net/bug.php?id=55701&edit=1 ID: 55701 Comment by: maciej dot sz at gmail dot com Reported by:b...@php.net Summary:GlobIterator throws LogicException with message 'The parent constructor was not Status: Assigned Type: Bug Package:SPL related Operating System: Linux, OSX PHP Version:5.3.8 Assigned To:cataphract Block user comment: N Private report: N New Comment: Not sure if this is the same issue, but I've experienced something very similar when extending SplFileObject (see Script 1 below). This might seem to be of very little importance, as no one would ever want to extend this class in that way. But with the introduction of traits this became a real problem, becouse using trait methods that share the same name with a SplFileObject method causes to throw the mentioned LogicException. This happens when the method is used in constructor prior to calling the parent constructor even if the trait method is aliased (see Script 2 below). Script 1: -- getRealPath(); parent::__construct($fname); } public function getRealPath() { return '/tmp/foo.txt'; } } $f1 = new MyFileObject(__FILE__); Script 2 -- newFileGetRealPath(); parent::__construct($new_fname); } } $f1 = new MyFileObject(__FILE__); Previous Comments: [2011-09-15 13:42:30] b...@php.net Description: Basic functionality doesn't work because it seems as the GlobIterator might needs some changes to work with this commit: http://marc.info/?l=php-cvs&m=130188548616717 Test script: --- next(); } while($g->valid()); Expected result: Empty output Actual result: -- PHP Fatal error: Uncaught exception 'LogicException' with message 'The parent constructor was not called: the object is in an invalid state ' in /private/tmp/x.php:6 Stack trace: #0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex() #1 {main} thrown in /private/tmp/x.php on line 6 Fatal error: Uncaught exception 'LogicException' with message 'The parent constructor was not called: the object is in an invalid state ' in /private/tmp/x.php:6 Stack trace: #0 /private/tmp/x.php(6): SplFileInfo->_bad_state_ex() #1 {main} thrown in /private/tmp/x.php on line 6 -- Edit this bug report at https://bugs.php.net/bug.php?id=55701&edit=1
Bug #60922 [Asn->Csd]: tests fail for mhash() and mhash_keygen_s2k() functions and MHASH_TIGER
Edit report at https://bugs.php.net/bug.php?id=60922&edit=1 ID: 60922 Updated by: m...@php.net Reported by:silvan at etoy dot com Summary:tests fail for mhash() and mhash_keygen_s2k() functions and MHASH_TIGER -Status: Assigned +Status: Closed Type: Bug Package:mhash related Operating System: Mac OS X PHP Version:5.4SVN-2012-01-29 (SVN) Assigned To:mike Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-01-31 10:29:16] jamie-lists at boxlightmedia dot com Also failing for me on 5.4RC6 (PHP 5.4.0-rc6-pl0-gentoo (cli) (built: Jan 30 2012 11:59:37) Result --- MHASH_GOST ok MHASH_TIGER: string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39" MHASH_TIGER: string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d" If I swap back to PHP 5.3.9-pl0-gentoo (cli) (built: Jan 30 2012 13:21:46), it returns the correct hash. [2012-01-30 12:35:30] m...@php.net Oh my, mhash compat mode of ext/hash eh? I totally missed that while fixing bug #60221. [2012-01-29 10:53:16] silvan at etoy dot com Description: make test failed test summary: mhash() test [ext/hash/tests/mhash_001.phpt] mhash_keygen_s2k() test [ext/hash/tests/mhash_003.phpt mhash_003.out: MHASH_TIGER: string(200) "67eac97b9dca0a47b1f6262f330264e4ce1c233760fe3255f642512fd3127929baccf1e758236b2768a4c2c0c06e118b19e40e2f04a5f745820fb8a99bdbc00698702a4d3120171856c4c94bda79ba1b4f60d509d7f8954da818a29797368dd47c1122aa" MHASH_TIGER: string(200) "470aca9d7bc9ea67e46402332f26f6b15532fe6037231cce297912d32f5142f6276b2358e7f1ccba8b116ec0c0c2a46845f7a5042f0ee41906c0db9ba9b80f82181720314d2a70981bba79da4bc9c4564d95f8d709d5604fd48d369797a218a862196f48" Test script: --- mhash_003.php foreach ($supported_hash_al as $hash=>$wanted) { $passwd = str_repeat($hash, 10); $salt = str_repeat($hash, 2); $result = mhash_keygen_s2k(constant($hash), $passwd, $salt, 100); if (!strcmp(bin2hex($result), $wanted)) { echo "$hash\nok\n"; } else { echo "$hash: "; var_dump($wanted); echo "$hash: "; var_dump(bin2hex($result)); } echo "\n"; } -- Edit this bug report at https://bugs.php.net/bug.php?id=60922&edit=1
Bug #61430 [Opn->Csd]: Transposed memset() params in sapi/fpm/fpm/fpm_shm.c
Edit report at https://bugs.php.net/bug.php?id=61430&edit=1 ID: 61430 Updated by: il...@php.net Reported by:michaelhood at gmail dot com Summary:Transposed memset() params in sapi/fpm/fpm/fpm_shm.c -Status: Open +Status: Closed Type: Bug Package:FPM related Operating System: Linux PHP Version:5.4.0 -Assigned To: +Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-03-18 21:39:53] michaelhood at gmail dot com Description: Affects all versions which bundle PHP-FPM. (>=5.3.3) In fpm_shm_alloc there is a call to memset() to initialise the segment. The parameters to memset() are transposed. Since we are [trying to] initialise with 0, but passing 0 to size_t, it silently fails to do anything. Patch attached, tested on 5.3.10 and 5.4.0. -- Edit this bug report at https://bugs.php.net/bug.php?id=61430&edit=1
[PHP-BUG] Bug #61443 [NEW]: Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly.
From: Operating system: Debian Sid PHP version: 5.4.0 Package: PHP options/info functions Bug Type: Bug Bug description:Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly. Description: Package: php5 Version: 5.4.0-2 Severity: important Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly. Test script: --- Expected result: end Actual result: -- Warning: ini_set(): Cannot enable zlib.output_compression - there has already been output in /home/alex/workspace/test/www/nouveauScript.php on line 3 end -- Edit bug report at https://bugs.php.net/bug.php?id=61443&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61443&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61443&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61443&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61443&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61443&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61443&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61443&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61443&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61443&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61443&r=support Expected behavior: https://bugs.php.net/fix.php?id=61443&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61443&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61443&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61443&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61443&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61443&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61443&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61443&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61443&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61443&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61443&r=mysqlcfg
[PHP-BUG] Bug #61442 [NEW]: SPL autoload issues Fatal Error if a handler throws exception
From: Operating system: Linux, FreeBSD PHP version: 5.3.10 Package: SPL related Bug Type: Bug Bug description:SPL autoload issues Fatal Error if a handler throws exception Description: If a handler is registered for autoloading (whether via spl_autoload_register() or __autoload()) and it throws an exception when a class is not found, the exception can not be caught as usual if a method of the target class is statically called. Instead, a Fatal Error: Class not found is issued (which is quite what the autoloader is meant to avoid!) Yet, when, e.g. trying to access a static field of that class, the exceptions get caught correctly. Tested on several PHP versions (5.3.3 - 5.3.10) on Linux and FreeBSD. Test script: --- :5 --- this is what gets output in case the exception is caught Actual result: -- xxx Fatal error: Class 'A' not found in on line 10 -- Edit bug report at https://bugs.php.net/bug.php?id=61442&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61442&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61442&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61442&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61442&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61442&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61442&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61442&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61442&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61442&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61442&r=support Expected behavior: https://bugs.php.net/fix.php?id=61442&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61442&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61442&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61442&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61442&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61442&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61442&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61442&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61442&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61442&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61442&r=mysqlcfg
Bug #61441 [Opn]: readlink returns operating system specific directory separators in result
Edit report at https://bugs.php.net/bug.php?id=61441&edit=1 ID: 61441 User updated by:daveespionage at gmail dot com Reported by:daveespionage at gmail dot com Summary:readlink returns operating system specific directory separators in result Status: Open Type: Bug Package:Filesystem function related Operating System: Windows 7 64 bit PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I should have clarified in the description, $_SERVER['DOCUMENT_ROOT'] in this case is pointed to a directory symlink created with 'mklink /D', that has the alias 'c:\sites\project' and resolves to 'c:\work\Project\wwwroot' Previous Comments: [2012-03-19 18:57:57] daveespionage at gmail dot com Description: readlink when called on a directory symlink in Windows 7 returns directory separators of '\', whereas seemingly most other filesystem functions return directory separators of '/' regardless of host operating system. Test script: --- '; echo 'Readlink: ' . readlink($_SERVER['DOCUMENT_ROOT']) . ''; ?> Expected result: Docroot: C:/sites/project Readlink: C:/work/Project/wwwroot Actual result: -- Docroot: C:/sites/project Readlink: C:\work\Project\wwwroot -- Edit this bug report at https://bugs.php.net/bug.php?id=61441&edit=1
[PHP-BUG] Bug #61441 [NEW]: readlink returns operating system specific directory separators in result
From: Operating system: Windows 7 64 bit PHP version: 5.3.10 Package: Filesystem function related Bug Type: Bug Bug description:readlink returns operating system specific directory separators in result Description: readlink when called on a directory symlink in Windows 7 returns directory separators of '\', whereas seemingly most other filesystem functions return directory separators of '/' regardless of host operating system. Test script: --- '; echo 'Readlink: ' . readlink($_SERVER['DOCUMENT_ROOT']) . ''; ?> Expected result: Docroot: C:/sites/project Readlink: C:/work/Project/wwwroot Actual result: -- Docroot: C:/sites/project Readlink: C:\work\Project\wwwroot -- Edit bug report at https://bugs.php.net/bug.php?id=61441&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61441&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61441&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61441&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61441&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61441&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61441&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61441&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61441&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61441&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61441&r=support Expected behavior: https://bugs.php.net/fix.php?id=61441&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61441&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61441&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61441&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61441&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61441&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61441&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61441&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61441&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61441&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61441&r=mysqlcfg
Bug #29992 [Com]: foreach by reference corrupts the array
Edit report at https://bugs.php.net/bug.php?id=29992&edit=1 ID: 29992 Comment by: paul dot dillinger at gmail dot com Reported by:fletch at pobox dot com Summary:foreach by reference corrupts the array Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.0.1 Block user comment: N Private report: N New Comment: Rasmus, Thanks for looking at this. I found the problem. I would still call it a bug, but I will describe it and you can decide. You are the man after all. You were right, I was passing a variable by reference in the few lines of code in front of my example above: foreach($this->data['external_'.$type] as &$item){ if(!empty($item['package'])){ $packages[] = $item; $library_names[] = $item['library_name']; unset($item); } } /* Code in example above goes here */ BUT, where I see this as a bug was: $packages (the array that was getting changed) was a new array created from the data of each $item. $packages was never being referenced, though the variable $item it was created from was. So, it should be a copy of the data and not THE data right? I fixed it by simply not trying to pass by reference and changing unset($item) to unset($this->data['external_'.$type]). Looking at it, that was the way to do it from the beginning. I see that, but I'm not sure why $packages gets changed down the road (it was correct immediately after this, but it and all copies of it change inside the next foreach). Any thoughts? Previous Comments: [2012-03-01 18:52:14] ras...@php.net Paul, my guess is that $item is a reference to an element in the $packages array going into this loop. Try using a different variable there. [2012-03-01 18:31:08] paul dot dillinger at gmail dot com Rasmus, I think they might be having the same problem than I am where the array literally changes as soon as I enter the foreach. I've given an in depth explanation at: http://codeigniter.com/forums/viewthread/201487/ , but I'll give a summary here. I'm using a newer version of PHP (5.3.8) and foreach is corrupting my array even when it's not being passed by reference. My original code read something like this: if(!empty($packages)){ /* $this->data['external_js'] is normal */ foreach($packages as $item){ /* $this->data['external_js'] has changed */ I noticed that one of my javascript files that this function is packing in to a single package as not present. Even more odd was another was in the package twice. So I started logging the $this->data['external_js'] array to FirePHP to see where the error was happening. Strangely enough it happened immediately after a foreach. I decided to make a separate copy of the array as a "just in case" and report that. It changed the exact same way. I need to literally hand build my JS packages as I can't figure out any way to stop this array from changing once it enters the foreach. Here is the troubleshooting code with comments: if(!empty($packages)){ // checking to see if there are multiple files to be packaged together if($type=='js'){ // check to see if it's javascript as that was the package that had the problem $ext_js_for_firephp = $this->data['external_js']; // found that $this->data['external_js'] was changing so I assign it to a new variable exclusively for logging to FirePHP, this variable exists NO WHERE ELSE in the code. fb_log('$ext_js_for_firephp before', $ext_js_for_firephp); // Log to FirePHP /* fb_log function for reference function fb_log($Label,$Object=null){ $firephp = FirePHP::getInstance(true); if(empty($Object)){ $Object = $Label; $Label = NULL; } $firephp->log($Object, $Label); } */ } foreach($packages as $item){ // Starting the foreach if($type=='js'){ // Again problem was with JS package changing fb_log('$ext_js_for_firephp after', $ext_js_for_firephp); // Log to FirePHP, but now the value is different. } // AGAIN this happened before I started logging the vars, so logging is not causing the issue. It's not an error with the logging output, as this is exactly what the file being built had in it. /* RESULT */ /* Before FirePHP returns: $ext_js_for_firephp before = array( [0] => array( ['template_id'] => 30 ['js_id'] => 9 ['id'] => 9 ['library_name'] => 'modernizr' ['file_name'] => 'modernizr.min.js' ['version_major'] => 2 ['version_minor'] => 0 ['version_build'] => 6 ['stati
Bug #61440 [Com]: proc_open() and shell escaping
Edit report at https://bugs.php.net/bug.php?id=61440&edit=1 ID: 61440 Comment by: aschulz4587 at gmail dot com Reported by:aschulz4587 at gmail dot com Summary:proc_open() and shell escaping Status: Open Type: Bug Package:CGI/CLI related Operating System: Vista/Win 7 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Note that this works if the bypass_shell flag it set. Also, popen() does not suffer from this problem. Previous Comments: [2012-03-19 18:23:01] aschulz4587 at gmail dot com Description: proc_open() does not seem to handle shell escaping of the script paths properly. Test script: --- array( 'pipe', 'r' ), // input 1 => array( 'pipe', 'w' ), // output 2 => array( 'file', 'NUL', 'a' ) // error ), $pipes // respective outputs ); fclose( $pipes[0] ); var_dump( stream_get_contents( $pipes[1] ) ); fclose( $pipes[1] ); proc_close($process); Expected result: $ php shelltest.php string(147) "PHP 5.3.4 (cli) (built: Dec 16 2010 00:06:20) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies " Actual result: -- $ php shelltest.php string(0) "" -- Edit this bug report at https://bugs.php.net/bug.php?id=61440&edit=1
[PHP-BUG] Bug #61440 [NEW]: proc_open() and shell escaping
From: Operating system: Vista/Win 7 PHP version: 5.4.0 Package: CGI/CLI related Bug Type: Bug Bug description:proc_open() and shell escaping Description: proc_open() does not seem to handle shell escaping of the script paths properly. Test script: --- array( 'pipe', 'r' ), // input 1 => array( 'pipe', 'w' ), // output 2 => array( 'file', 'NUL', 'a' ) // error ), $pipes // respective outputs ); fclose( $pipes[0] ); var_dump( stream_get_contents( $pipes[1] ) ); fclose( $pipes[1] ); proc_close($process); Expected result: $ php shelltest.php string(147) "PHP 5.3.4 (cli) (built: Dec 16 2010 00:06:20) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies " Actual result: -- $ php shelltest.php string(0) "" -- Edit bug report at https://bugs.php.net/bug.php?id=61440&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61440&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61440&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61440&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61440&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61440&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61440&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61440&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61440&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61440&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61440&r=support Expected behavior: https://bugs.php.net/fix.php?id=61440&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61440&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61440&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61440&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61440&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61440&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61440&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61440&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61440&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61440&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61440&r=mysqlcfg
[PHP-BUG] Req #61439 [NEW]: POST and other methods input data handling
From: Operating system: windows PHP version: 5.4.0 Package: *General Issues Bug Type: Feature/Change Request Bug description:POST and other methods input data handling Description: when sending multipart/form-data via a POST method, PHP internally parses all variables into $_POST and files into $_FILES. but the parsing is not done with any other method (PUT,PATCH,PROPFIND ..) additionally, sending POST with multipart/form-data makes php://input unavailable. so there is no universal parsing solution which covers all methods. there should be a setting option (php.ini) where i can determine which particular methods i want the internal parser run for (eg. "parse_input_methods = POST,PUT,PATCH") and/or there should be an option for disabling that internal parser completely. -- Edit bug report at https://bugs.php.net/bug.php?id=61439&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61439&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61439&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61439&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61439&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61439&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61439&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61439&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61439&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61439&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61439&r=support Expected behavior: https://bugs.php.net/fix.php?id=61439&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61439&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61439&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61439&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61439&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61439&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61439&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61439&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61439&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61439&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61439&r=mysqlcfg
Bug #61434 [Nab]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 User updated by:info at ongod dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 Status: Not a bug Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: it is Should be clean code for check. php5.4 not normal work. but php5.3.10 normal work in the same server. who tell me why this ? http://www.ongod.org/test/phpinfo.php Web page compressed?No Compression type? none Size, Markup (bytes)83,611 Size, Compressed (bytes)0 Compression % 0.0 php5.3.10 http://mail.ipv6china.com/phpinfo.php Web page compressed?Yes Compression type? gzip Size, Markup (bytes)87,124 Size, Compressed (bytes)13,730 Compression % 84.2 check from http://www.gidnetwork.com/tools/gzip-test.php Previous Comments: [2012-03-19 14:14:54] paj...@php.net ok, not a bug but a support issue. @info at ongod dot org Please ask further support on the PHP general mailing list or any other support channel, thanks! [2012-03-19 14:10:56] a...@php.net I cannot reproduce the issue, tried with the latest php 5.4 and IIS7. IIS7 has compression turned off and the php.ini has both zlib.output_compression=on and zlib.output_compression_level=-1 set. The page is merely a phpinfo() page. Here the simple ping pong: GET /i.php HTTP/1.1 Host: localhost Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP/1.1 200 OK Content-Type: text/html Content-Encoding: gzip Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-Powered-By: PHP/5.4.1RC1-dev Date: Mon, 19 Mar 2012 14:00:09 GMT Content-Length: 6182 The output compression seems to work. @info at ongod dot org Could you please try such a simple page scenario and post the request/response headers? [2012-03-19 14:01:26] nacin at wordpress dot org I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks like WP never has. [2012-03-19 11:40:20] info at ongod dot org Security reasons, I would also send an email to you. [2012-03-19 11:25:40] m...@php.net zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
[PHP-BUG] Bug #61437 [NEW]: Illegal stub for phar
From: Operating system: Archlinux PHP version: 5.3.10 Package: PHAR related Bug Type: Bug Bug description:Illegal stub for phar Description: It's not possible to add spaces in the __halt_compiler argument list. Test script: --- setStub( "https://bugs.php.net/bug.php?id=61437&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61437&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61437&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61437&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61437&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61437&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61437&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61437&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61437&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61437&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61437&r=support Expected behavior: https://bugs.php.net/fix.php?id=61437&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61437&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61437&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61437&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61437&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61437&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61437&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61437&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61437&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61437&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61437&r=mysqlcfg
Bug #61434 [Asn->Nab]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Updated by: paj...@php.net Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Assigned +Status: Not a bug Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 -Assigned To:mike +Assigned To: Block user comment: N Private report: N New Comment: ok, not a bug but a support issue. @info at ongod dot org Please ask further support on the PHP general mailing list or any other support channel, thanks! Previous Comments: [2012-03-19 14:10:56] a...@php.net I cannot reproduce the issue, tried with the latest php 5.4 and IIS7. IIS7 has compression turned off and the php.ini has both zlib.output_compression=on and zlib.output_compression_level=-1 set. The page is merely a phpinfo() page. Here the simple ping pong: GET /i.php HTTP/1.1 Host: localhost Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP/1.1 200 OK Content-Type: text/html Content-Encoding: gzip Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-Powered-By: PHP/5.4.1RC1-dev Date: Mon, 19 Mar 2012 14:00:09 GMT Content-Length: 6182 The output compression seems to work. @info at ongod dot org Could you please try such a simple page scenario and post the request/response headers? [2012-03-19 14:01:26] nacin at wordpress dot org I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks like WP never has. [2012-03-19 11:40:20] info at ongod dot org Security reasons, I would also send an email to you. [2012-03-19 11:25:40] m...@php.net zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. [2012-03-19 11:22:09] info at ongod dot org if you will, I can offer server account give you for check. 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61434 [Com]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Comment by: a...@php.net Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 Status: Assigned Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: I cannot reproduce the issue, tried with the latest php 5.4 and IIS7. IIS7 has compression turned off and the php.ini has both zlib.output_compression=on and zlib.output_compression_level=-1 set. The page is merely a phpinfo() page. Here the simple ping pong: GET /i.php HTTP/1.1 Host: localhost Connection: keep-alive Cache-Control: max-age=0 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 HTTP/1.1 200 OK Content-Type: text/html Content-Encoding: gzip Vary: Accept-Encoding Server: Microsoft-IIS/7.5 X-Powered-By: PHP/5.4.1RC1-dev Date: Mon, 19 Mar 2012 14:00:09 GMT Content-Length: 6182 The output compression seems to work. @info at ongod dot org Could you please try such a simple page scenario and post the request/response headers? Previous Comments: [2012-03-19 14:01:26] nacin at wordpress dot org I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks like WP never has. [2012-03-19 11:40:20] info at ongod dot org Security reasons, I would also send an email to you. [2012-03-19 11:25:40] m...@php.net zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. [2012-03-19 11:22:09] info at ongod dot org if you will, I can offer server account give you for check. [2012-03-19 11:15:06] info at ongod dot org I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61419 [Fbk->Opn]: Upload Progress returning empty array
Edit report at https://bugs.php.net/bug.php?id=61419&edit=1 ID: 61419 User updated by:jasmin_z at hotmail dot com Reported by:jasmin_z at hotmail dot com Summary:Upload Progress returning empty array -Status: Feedback +Status: Open Type: Bug Package:Session related Operating System: Debian 6 Squeeze x64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hi and thanks for the feedback. Uploading huge files was the first thing I tried (upload size limit set to 600MB and uploading a 500MB file from another network). Data returned _while_ uploading is an empty array. If you need more info (PHP, nginx configuration files, ...) please let me know. Previous Comments: [2012-03-19 05:44:43] larue...@php.net Plz use a huge size file to test, since you set the session.upload_progress.cleanup on, which means, the upload info will be clean as soon as all the post data was parsed. see: http://cn.php.net/manual/en/session.configuration.php#ini.session.upload- progress.cleanup [2012-03-16 18:47:30] jasmin_z at hotmail dot com Description: Session upload tracking is returning empty array when queued. PHP is build from source using following configure string: ./configure --prefix=/usr/local --sysconfdir=/etc/php --localstatedir=/var --libdir=/usr/lib64 --with-layout=GNU --with-config-file-path=/etc/php --with-config-file-scan-dir=/etc/php/conf.d --with-openssl --with-mcrypt --with-zlib --with-tidy --with-bz2 --with-curl --with-curlwrappers --with-mhash --with-pear --with-imap=/usr/lib64/ --with-imap-ssl --with-kerberos --with-gettext --with-pic --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-mysql-sock=/var/run/mysql/mysql.sock --with-gd --with-xsl --with-xmlrpc --with-mm --with-freetype-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-fpm-user=www-data --with-fpm-group=www-data --enable-gd-native-ttf --enable-pcntl --enable-calendar --enable-ftp --enable-exif --enable-intl --enable-mbstring --enable-sockets --enable-zip --enable-soap --enable-fpm --disable-debug --disable-rpath Webserver used is nginx (1.0.14) built from source. Test script: --- http://www.neowin.net/forum/topic/1063478-php-540-upload-tracking-returning-empty-array/ Expected result: Array containing information about files being uploaded. Actual result: -- array(0) { } -- Edit this bug report at https://bugs.php.net/bug.php?id=61419&edit=1
Bug #61434 [Com]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Comment by: nacin at wordpress dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 Status: Assigned Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks like WP never has. Previous Comments: [2012-03-19 11:40:20] info at ongod dot org Security reasons, I would also send an email to you. [2012-03-19 11:25:40] m...@php.net zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. [2012-03-19 11:22:09] info at ongod dot org if you will, I can offer server account give you for check. [2012-03-19 11:15:06] info at ongod dot org I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. [2012-03-19 10:57:29] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #46262 [Com]: FreeTDS error.
Edit report at https://bugs.php.net/bug.php?id=46262&edit=1 ID: 46262 Comment by: programmer at finner dot de Reported by:manohar dot angani at gmail dot com Summary:FreeTDS error. Status: No Feedback Type: Bug Package:MSSQL related Operating System: Linux PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Bug still in 5.4. Assuming, $db is a database object which provides a connection via PDO/dblib, try connect(); $query = $con->prepare("select id from table where param = ?"); while (true) { $query->bindParam(1, 4711); $query->execute(); while ($row = $query->fetch(PDO::FETCH_ASSOC) { (do something with result) } } ?> If you provide different values at $quer->bindParam(), it works OK, also, if you prepare the query always new within the while loop. If you reuse the prepared query with the same parameter as in the loop before, the mentioned error will occur. Previous Comments: [2008-10-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-10-14 00:57:04] ka...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2008-10-09 05:55:29] manohar dot angani at gmail dot com Description: We are using freetds .64 and it gives us an error when the same procedure is invoked twice with the same parameter. Error: the XML response that was returned from the server is invalid. Received: sp_helpconstraint_new mt_cell_pull passed Array ( [0] => 0 [1] => 0 [2] => (null) [0] (severity 0) [(null)] [3] => 0 [4] => 0 ) 1 sp_columns mt_cell_pull passed sp_helpconstraint_new mt_dimension_selected passed Array ( [0] => 0 [1] => 0 [2] => (null) [0] (severity 0) [(null)] [3] => 0 [4] => 0 ) 1 sp_columns mt_dimension_selected passed sp_helpconstraint_new mt_cell_pull passed Array ( [0] => HY000 [1] => 20019 [2] => Attempt to initiate a new Adaptive Server operation with results pending [20019] (severity 7) [(null)] [3] => 0 [4] => 7 [5] => Success ) 1 DBEntidad::DBEntidad - tableInfo without data - Table: mt_cell_pull-Query Error: Attempt to initiate a new Adaptive Server operation with results pending [20019] (severity 7) [(null)] Expected result: The SQL error is thrown by FreeTDS and it shouldn't throw it. Actual result: -- SQL error .. -- Edit this bug report at https://bugs.php.net/bug.php?id=46262&edit=1
Bug #61423 [Csd]: gzip compression fails
Edit report at https://bugs.php.net/bug.php?id=61423&edit=1 ID: 61423 User updated by:borrible13th at gmx dot net Reported by:borrible13th at gmx dot net Summary:gzip compression fails Status: Closed Type: Bug Package:SOAP related Operating System: ALL PHP Version:5.4.0 Assigned To:iliaa Block user comment: N Private report: N New Comment: Can't see a bugfix in the source code whether in the branch for 5.4 or in the trunk! The magic number (1) is still hard coded. Do I miss something? Previous Comments: [2012-03-18 15:15:47] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-17 02:01:29] borrible13th at gmx dot net Description: SOAP fails to compress with gzip encoding (compression level greater 0): it warns "encoding mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or ZLIB_ENCODING_DEFLATE" and throws SoapFault with "SoapClient::__doRequest() returned non string value". Cause: Zlib introduces new constants ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP, ZLIB_ENCODING_DEFLATE and redefines FORCE_GZIP as ZLIB_ENCODING_GZIP and FORCE_DEFLATE as ZLIB_ENCODING_DEFLATE. In php_http.c, line 263ff. the call to gzencode is prepared with an hard coded magic number (1) for the gzip encoding: gzencode(data, level, 1). It should be gzencode(data, level, FORCE_GZIP) or gzencode(data, level, ZLIB_ENCODING_GZIP), because the magic number is now defined as 0x1f (31). Test script: --- new SoapClient($wsdl, array('soap_version' => SOAP_1_2, 'compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | 1 )); Expected result: Call gzencode(data, level, FORCE_GZIP) (or gzencode(data, level, ZLIB_ENCODING_GZIP)), so it returns compressed data. Actual result: -- gzencode(data, level, 1) is called, so it returns always false and warns "encoding mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or ZLIB_ENCODING_DEFLATE". -- Edit this bug report at https://bugs.php.net/bug.php?id=61423&edit=1
Req #54243 [Opn]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1 ID: 54243 User updated by:anil at saog dot net Reported by:anil at saog dot net Summary:Shorter syntax for closures Status: Open Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Guys, please calm down. I have no idea why you write these comments in a heat but this issue is just a wishing. Also, readability is a non-objective property which generally differs person to person, but the "key" is "shorter means readable". By the way, did you ever inspect c# - linq syntax? C# : ...Where((a,b) => a == b) PHP : ...Where(function($a, $b){ return $a == $b; }) MY : ...Where($($a, $b, {$a == $b})) readability? yes of course readability... so you think you are better than microsoft on readability? If you do not agree of course it is okay just tell it (like a human) otherwise keep your ignoble and invaluable ideas to yourself. Previous Comments: [2012-03-19 11:13:20] ninzya at inbox dot lv I think the proposed syntax is not readable at all. Rather it looks like you have been affected by a "wannabe jQuery inventor". How do you come up with a dollar sign being "readable"? How do you define "readable code"? If you read your code, you read it as "dollar, dollar, bracket, dollar, dollar... whatever, dollar". Is this what you call "readability"? However I do agree that the "use()" clause of closures sometimes bloats the code a little bit, especially if the closure is importing a lot of variables from its context. [2012-03-19 09:08:09] danko at very dot lv Um, no, *that* is unreadable. The original syntax can easily be made readable if you do care: $myObject->MyMethod( 'abc', function ($a) use ($b) { return $a == $b; } ); There you go. As readable as it gets - just add some newlines and tabs. On the other hand, a soup of brackets and dollar signs can't be readable regardless of formatting. [2011-03-13 16:16:45] anil at saog dot net Changed package [2011-03-13 16:09:36] anil at saog dot net Description: Current closure syntax makes the code a little bit unreadable and also shortening the syntax of a handy thing like this seems more logical. Test script: --- As of now "closure" syntax is: function ($a) use($b){ return $a == $b; } Passing a closure to any other scope: $myObject = new myObject (); $myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; }); Expected result: My short syntax candidate is: $([arg1],[arg2],[arg...], {[method body]}, [scope_var1],[scope_var2],[scope_var...]) So passing with use token syntax: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b}, $b)); Without "use" token: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b})); With more than one method argument: $myObject = new myObject (); $myObject->MyMethod('abc', $($a,$k,$p,{$a == $b})); -- Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
Bug #60569 [Csd->Asn]: Nullbyte truncates Exception $message.
Edit report at https://bugs.php.net/bug.php?id=60569&edit=1 ID: 60569 User updated by:hanskrentel at yahoo dot de Reported by:hanskrentel at yahoo dot de Summary:Nullbyte truncates Exception $message. -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Fedora 14 PHP Version:5.3.8 Assigned To:iliaa Block user comment: N Private report: N New Comment: Re-open because it is not fixed. Previous Comments: [2012-03-14 10:52:47] hanskrentel at yahoo dot de Tested against PHP trunk Revision: 324199 (Windows), there still is truncation on the NULL char. $original = "Null Char \0 Test."; echo "Original Message..: ", $original, "\n"; $e = new Exception($original); $processed = $e->getMessage(); echo "Processed Message.: ", $processed, "\n"; [2012-03-11 18:15:12] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2012-03-11 18:15:03] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=324112 Log: Fixed bug #60569 (Nullbyte truncates Exception $message). [2011-12-20 04:17:32] hanskrentel at yahoo dot de Description: When an Exception class is instantiated and a string contain a nullbyte character ("\0") is used as $message, Exception::getMessage() returns a truncated string (the protected member Exception::$message is truncated as well). Looks like a duplicate of https://bugs.php.net/bug.php?id=50085 which outlined this as documentation problem. No idea why this is a documentation problem. Test script: --- $e = new Exception("test\0me"); echo $e->getMessage(); Expected result: output (not displaying non-printable characters): testme Actual result: -- output (not displaying non-printable characters): test -- Edit this bug report at https://bugs.php.net/bug.php?id=60569&edit=1
Bug #61434 [Fbk->Asn]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 User updated by:info at ongod dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Feedback +Status: Assigned Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: Security reasons, I would also send an email to you. Previous Comments: [2012-03-19 11:25:40] m...@php.net zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. [2012-03-19 11:22:09] info at ongod dot org if you will, I can offer server account give you for check. [2012-03-19 11:15:06] info at ongod dot org I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. [2012-03-19 10:57:29] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. [2012-03-19 10:47:10] info at ongod dot org I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
[PHP-BUG] Req #61435 [NEW]: PHP-FPM logs are not readable by group/others by default
From: Operating system: PHP version: 5.3.10 Package: FPM related Bug Type: Feature/Change Request Bug description:PHP-FPM logs are not readable by group/others by default Description: Hello, errorlog, slowlog and accesslog are created with permissions set to 0600 by default on PHP 5.3 and 5.4. Those files are often owned by root (at least in our setup but probably in a lot of setups), which makes it not convenient for developers to read them. They may contain useful information, such as PHP crashes. Failing to fix it with umask in php-fpm init script (not mentioning the fact that it would affect php scripts too), I wrote a simple patch against PHP-5.3.10 to modify open() calls with 0644 perms. Note that Apache uses 0644 by default for its logs. Olivier -- Edit bug report at https://bugs.php.net/bug.php?id=61435&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61435&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61435&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61435&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61435&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61435&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61435&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61435&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61435&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61435&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61435&r=support Expected behavior: https://bugs.php.net/fix.php?id=61435&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61435&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61435&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61435&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61435&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61435&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61435&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61435&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61435&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61435&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61435&r=mysqlcfg
Bug #61434 [Opn->Fbk]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Updated by: m...@php.net Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Open +Status: Feedback Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: zlib.output_compression can be disabled at runtime at later stage in PHP 5.4. I'd probably be lost on a Windows box, so I don't think I could help you there. Previous Comments: [2012-03-19 11:22:09] info at ongod dot org if you will, I can offer server account give you for check. [2012-03-19 11:15:06] info at ongod dot org I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. [2012-03-19 10:57:29] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. [2012-03-19 10:47:10] info at ongod dot org I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? [2012-03-19 10:39:50] m...@php.net Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. 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=61434 -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61434 [Asn->Opn]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 User updated by:info at ongod dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Assigned +Status: Open Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: if you will, I can offer server account give you for check. Previous Comments: [2012-03-19 11:15:06] info at ongod dot org I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. [2012-03-19 10:57:29] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. [2012-03-19 10:47:10] info at ongod dot org I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? [2012-03-19 10:39:50] m...@php.net Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. [2012-03-19 10:31:29] info at ongod dot org Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61415 [Opn]: zend_alter_ini_entry failuers
Edit report at https://bugs.php.net/bug.php?id=61415&edit=1 ID: 61415 User updated by:info at simonecaruso dot com Reported by:info at simonecaruso dot com Summary:zend_alter_ini_entry failuers Status: Open Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I really would like debug php and find what's wrong. For now i moved from PHP_INI_STAGE_RUNTIME to PHP_INI_STAGE_ACTIVATE and the problem disappeared. But now i get this in logs when apache stops: []/Zend/zend_ini.c(278) : Freeing 0x7F63E5BB4908 (72 bytes), script=/home/www- data/mesogeamag.it/html/index.php []/Zend/zend_ini.c(279) : Freeing 0x7F63E5BB49A8 (64 bytes), script=/home/www- data/mesogeamag.it/html/index.php []/Zend/zend_alloc.c(2454) : Actual location (location was relayed) []/Zend/zend_hash.c(250) : Freeing 0x7F63E5BB4A40 (84 bytes), script=/home/www- data/mesogeamag.it/html/index.php []/Zend/zend_ini.c(289) : Freeing 0x7F63E5BB4AE8 (64 bytes), script=/home/www- data/mesogeamag.it/html/index.php Thank you for help Previous Comments: [2012-03-17 18:43:13] cataphr...@php.net The fact it worked in 5.2 doesn't imply your code had no bug. It may mean that a bug has always existed, but by luck it wasn't triggered by 5.2. Of course, if you could identify the specific commit that triggers the problem, it could shed light on this problem. If you can automate the tests, you can easily run something a bisection procedure to find such commit. [2012-03-16 23:27:31] info at simonecaruso dot com I don't think it's a my module problem because with 5.2 i dont have this problem (i did the sames tests for 5.3, same apache, same config), i moved to 5.3 from less than one month. I don't think it's a concurrency related issue too, the failure are too much rare i think. I did a diff between 5.2 and 5.3 and saw there are major changes to fopen_wrapper.c, and i have this problem only for open_basedir, that's why i opened the bug. I'll try with other stages in the hope this can help. [2012-03-16 21:41:22] cataphr...@php.net I assume you're using the prefork SAPI, as the stack trace shows you're not using ZTS. In that case, I find strange your claim this is a concurrency issue. More likely, the problem would be in your module and I don't know anything about Apache modules lifecycle to even guess where the problem could be. You could try passing another value for stage as the ini update handler for open_basedir can never fail for stages PHP_INI_STAGE_STARTUP, PHP_INI_STAGE_SHUTDOWN, PHP_INI_STAGE_ACTIVATE,PHP_INI_STAGE_DEACTIVATE, but this would most likely just mask the underlying problem. You can also try running Apache under valgrind with --trace-children and see if you get something. [2012-03-16 18:07:23] info at simonecaruso dot com It breaks always at zend_ini.c:300 The data i pass is always correct, but sometimes i get a FAILURE. Breakpoint 3, zend_alter_ini_entry_ex (name=0x7f2de6128199 "open_basedir", name_length=13, new_value=0x7f2debd02e48 "/tmp/:/usr/share/php/:.:/home/www- data/musitalia.com/html/", new_value_length=58, modify_type=4, stage=16, force_change=0) at /root/php-5.3.10/Zend/zend_ini.c:300 300 return FAILURE; (gdb) bt full #0 zend_alter_ini_entry_ex (name=0x7f2de6128199 "open_basedir", name_length=13, new_value=0x7f2debd02e48 "/tmp/:/usr/share/php/:.:/home/www- data/musitalia.com/html/", new_value_length=58, modify_type=4, stage=16, force_change=0) at /root/php-5.3.10/Zend/zend_ini.c:300 ini_entry = 0x7f2debb35d30 duplicate = 0x7f2debaf3140 'Z' , "N\230D\300ZQ\twe- \177" modifiable = 7 '\a' modified = 1 '\001' #1 0x7f2de77f00d0 in zend_alter_ini_entry (name=0x7f2de6128199 "open_basedir", name_length=13, new_value=0x7f2debd02e48 "/tmp/:/usr/share/php/:.:/home/www- data/musitalia.com/html/", new_value_length=58, modify_type=4, stage=16) at /root/php-5.3.10/Zend/zend_ini.c:249 No locals. #2 0x7f2de6126c1d in mod_vhost_ldap_translate_name (r=0x7f2debd01570) at mod_vhost_ldap_ng.c:862 reqc = 0x7f2deb4b0510 conf = 0x7f2deba31038 core = 0x7f2deb9695e8 ld = 0x0 realfile = 0x0 alias = 0x0 i = 0 ret = 0 str = {0x0, 0x0, 0x0} ldapmsg = 0x0 vhostentry = 0x0 openbasedir = 0x7f2debd02e48 "/tmp/:/usr/share/php/:.:/home/www- data/musitalia.com/html/" include = 0x7f2debd02e08 "/tmp/:/usr/share/php/:.:/home/www- data/musitalia.com/html/" -
Bug #61434 [Fbk->Asn]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 User updated by:info at ongod dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Feedback +Status: Assigned Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: I have try check it. try chang back use php5.3.10 normal for zlib.output_compression. but the php5.4 not normal work in the same site. now I chage www.xiaoyu.net in php5.3.10. and http://www.yessan.org/ site use php5.4. all site run wordpress code. So I think php5.4 should some bug in iis7.5. Previous Comments: [2012-03-19 10:57:29] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. [2012-03-19 10:47:10] info at ongod dot org I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? [2012-03-19 10:39:50] m...@php.net Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. [2012-03-19 10:31:29] info at ongod dot org Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1 ID: 54243 Comment by: ninzya at inbox dot lv Reported by:anil at saog dot net Summary:Shorter syntax for closures Status: Open Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I think the proposed syntax is not readable at all. Rather it looks like you have been affected by a "wannabe jQuery inventor". How do you come up with a dollar sign being "readable"? How do you define "readable code"? If you read your code, you read it as "dollar, dollar, bracket, dollar, dollar... whatever, dollar". Is this what you call "readability"? However I do agree that the "use()" clause of closures sometimes bloats the code a little bit, especially if the closure is importing a lot of variables from its context. Previous Comments: [2012-03-19 09:08:09] danko at very dot lv Um, no, *that* is unreadable. The original syntax can easily be made readable if you do care: $myObject->MyMethod( 'abc', function ($a) use ($b) { return $a == $b; } ); There you go. As readable as it gets - just add some newlines and tabs. On the other hand, a soup of brackets and dollar signs can't be readable regardless of formatting. [2011-03-13 16:16:45] anil at saog dot net Changed package [2011-03-13 16:09:36] anil at saog dot net Description: Current closure syntax makes the code a little bit unreadable and also shortening the syntax of a handy thing like this seems more logical. Test script: --- As of now "closure" syntax is: function ($a) use($b){ return $a == $b; } Passing a closure to any other scope: $myObject = new myObject (); $myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; }); Expected result: My short syntax candidate is: $([arg1],[arg2],[arg...], {[method body]}, [scope_var1],[scope_var2],[scope_var...]) So passing with use token syntax: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b}, $b)); Without "use" token: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b})); With more than one method argument: $myObject = new myObject (); $myObject->MyMethod('abc', $($a,$k,$p,{$a == $b})); -- Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
Bug #61434 [Asn->Fbk]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Updated by: m...@php.net Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Assigned +Status: Feedback Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Sorry, I cannot assist you searching the code. Previous Comments: [2012-03-19 10:47:10] info at ongod dot org I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? [2012-03-19 10:39:50] m...@php.net Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. [2012-03-19 10:31:29] info at ongod dot org Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61434 [Fbk->Asn]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 User updated by:info at ongod dot org Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Feedback +Status: Assigned Type: Bug Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 Assigned To:mike Block user comment: N Private report: N New Comment: I am using wordpress 3.3.1 code. run site is http://www.xiaoyu.net and http://www.yessan.org/ How I check in wordpress code? Previous Comments: [2012-03-19 10:39:50] m...@php.net Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. [2012-03-19 10:31:29] info at ongod dot org Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
Bug #61434 [Opn->Fbk]: zlib.output_compression not normal work in IIS7.5
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1 ID: 61434 Updated by: m...@php.net Reported by:info at ongod dot org Summary:zlib.output_compression not normal work in IIS7.5 -Status: Open +Status: Feedback Type: Bug -Package:Zip Related +Package:Zlib related Operating System: windows2008R2x64 PHP Version:5.4.0 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Is you're site publicly viewable? Check if you do not call ini_set("zlib.output_compression", false) in your code. Previous Comments: [2012-03-19 10:31:29] info at ongod dot org Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit this bug report at https://bugs.php.net/bug.php?id=61434&edit=1
[PHP-BUG] Bug #61434 [NEW]: zlib.output_compression not normal work in IIS7.5
From: Operating system: windows2008R2x64 PHP version: 5.4.0 Package: Zip Related Bug Type: Bug Bug description:zlib.output_compression not normal work in IIS7.5 Description: I am running php5.4 in IIS7.5 when I config zlib.output_compression= on and zlib.output_compression_level = -1 in php.ini, it can't compression out. I am use the tools for check site. http://www.gidnetwork.com/tools/gzip-test.php http://tool.chinaz.com/gzips/ -- Edit bug report at https://bugs.php.net/bug.php?id=61434&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61434&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61434&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61434&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61434&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61434&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61434&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61434&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61434&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61434&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61434&r=support Expected behavior: https://bugs.php.net/fix.php?id=61434&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61434&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61434&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61434&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61434&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61434&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61434&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61434&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61434&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61434&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61434&r=mysqlcfg
[PHP-BUG] Bug #61433 [NEW]: php hangs using fastcgi, user_ini.filename with On/Off in user.ini-file on IIS6
From: Operating system: Windows Server 2003 Standard PHP version: 5.4.0 Package: IIS related Bug Type: Bug Bug description:php hangs using fastcgi, user_ini.filename with On/Off in user.ini-file on IIS6 Description: Use FastCGI 1.5 RTW (x86) for IIS (fcgiext.dll). In php.ini: user_ini.filename = foo.php.ini When a folder has a foo.php.ini with the following content: On Ie: CRLF, On, CRLF. The php-request will hang and write "Application popup: : " to syslog (event viewer -> System). Does not happen on IIS7/Win 2008. Test script: --- foo.php.ini: php_flagdisplay_errorsOff php_flaglog_errorsOn test.php: Expected result: phpinfo Actual result: -- php hangs -- Edit bug report at https://bugs.php.net/bug.php?id=61433&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61433&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61433&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61433&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61433&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61433&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61433&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61433&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61433&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61433&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61433&r=support Expected behavior: https://bugs.php.net/fix.php?id=61433&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61433&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61433&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61433&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61433&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61433&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61433&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61433&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61433&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61433&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61433&r=mysqlcfg
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1 ID: 54243 Comment by: danko at very dot lv Reported by:anil at saog dot net Summary:Shorter syntax for closures Status: Open Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Um, no, *that* is unreadable. The original syntax can easily be made readable if you do care: $myObject->MyMethod( 'abc', function ($a) use ($b) { return $a == $b; } ); There you go. As readable as it gets - just add some newlines and tabs. On the other hand, a soup of brackets and dollar signs can't be readable regardless of formatting. Previous Comments: [2011-03-13 16:16:45] anil at saog dot net Changed package [2011-03-13 16:09:36] anil at saog dot net Description: Current closure syntax makes the code a little bit unreadable and also shortening the syntax of a handy thing like this seems more logical. Test script: --- As of now "closure" syntax is: function ($a) use($b){ return $a == $b; } Passing a closure to any other scope: $myObject = new myObject (); $myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; }); Expected result: My short syntax candidate is: $([arg1],[arg2],[arg...], {[method body]}, [scope_var1],[scope_var2],[scope_var...]) So passing with use token syntax: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b}, $b)); Without "use" token: $myObject = new myObject (); $myObject->MyMethod('abc', $($a, {$a == $b})); With more than one method argument: $myObject = new myObject (); $myObject->MyMethod('abc', $($a,$k,$p,{$a == $b})); -- Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1