[PHP-BUG] Bug #60923 [NEW]: Failing tests for sapi/cli
From: Operating system: GNU/Linux (Fedora 16) PHP version: 5.4SVN-2012-01-29 (SVN) Package: CGI/CLI related Bug Type: Bug Bug description:Failing tests for sapi/cli Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit bug report at https://bugs.php.net/bug.php?id=60923&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60923&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60923&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60923&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60923&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60923&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60923&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60923&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60923&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60923&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60923&r=support Expected behavior: https://bugs.php.net/fix.php?id=60923&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60923&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60923&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60923&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60923&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60923&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60923&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60923&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60923&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60923&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60923&r=mysqlcfg
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1 ID: 60923 Comment by: robertbasic dot com at gmail dot com Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli Status: Feedback Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Block user comment: N Private report: N New Comment: Will do. By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, looks like that var_dump(`$php -n -v`); first prints out the PHP version (the result from php -n -v) and then var_dumps a NULL, whereas it should var_dump the result from php -n -v. Actually, all these failing tests are this kind of thing: printing the result, var_dumping NULL, instead of var_dumping the result. What's strange, is that, for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one does this (the 2nd), the other 2 work as expected. Given that this works for RC6, I'm looking at commits since then, to see if anything from there is causing this. Any hints on what should I do to check is my system affecting this somehow? I'm using the test instructions you posted on codepad some time ago. Thanks! Previous Comments: [2012-01-29 13:50:42] ras...@php.net I am not seeing these failures here. Could you dig into one of them to see if you can figure out why it is failing for you? [2012-01-29 12:20:21] robertbasic dot com at gmail dot com Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1 ID: 60923 Comment by: robertbasic dot com at gmail dot com Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli Status: Feedback Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Block user comment: N Private report: N New Comment: Hello again! I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through those commits. What I've managed to do so far is to find what commit is causing the tests to fail (at least I think it's this one): http://svn.php.net/viewvc?view=revision&revision=322743 The r322743 of the code has the tests failing, while the one prior to it (r322678) has the tests passing. Sadly my C skills are almost non-existent, so I can't promise a patch, but will continue to poke around it. Previous Comments: [2012-01-29 14:24:04] robertbasic dot com at gmail dot com Will do. By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, looks like that var_dump(`$php -n -v`); first prints out the PHP version (the result from php -n -v) and then var_dumps a NULL, whereas it should var_dump the result from php -n -v. Actually, all these failing tests are this kind of thing: printing the result, var_dumping NULL, instead of var_dumping the result. What's strange, is that, for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one does this (the 2nd), the other 2 work as expected. Given that this works for RC6, I'm looking at commits since then, to see if anything from there is causing this. Any hints on what should I do to check is my system affecting this somehow? I'm using the test instructions you posted on codepad some time ago. Thanks! [2012-01-29 13:50:42] ras...@php.net I am not seeing these failures here. Could you dig into one of them to see if you can figure out why it is failing for you? -------- [2012-01-29 12:20:21] robertbasic dot com at gmail dot com Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1 ID: 60923 Comment by: robertbasic dot com at gmail dot com Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli Status: Feedback Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Block user comment: N Private report: N New Comment: Think I narrowed it down even more. Seems to me the problem is in the new php_output_stderr function - when I comment it out, the tests pass again. I'll attach a diff to show what I did. Previous Comments: [2012-01-29 16:21:26] robertbasic dot com at gmail dot com Hello again! I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through those commits. What I've managed to do so far is to find what commit is causing the tests to fail (at least I think it's this one): http://svn.php.net/viewvc?view=revision&revision=322743 The r322743 of the code has the tests failing, while the one prior to it (r322678) has the tests passing. Sadly my C skills are almost non-existent, so I can't promise a patch, but will continue to poke around it. ---- [2012-01-29 14:24:04] robertbasic dot com at gmail dot com Will do. By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, looks like that var_dump(`$php -n -v`); first prints out the PHP version (the result from php -n -v) and then var_dumps a NULL, whereas it should var_dump the result from php -n -v. Actually, all these failing tests are this kind of thing: printing the result, var_dumping NULL, instead of var_dumping the result. What's strange, is that, for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one does this (the 2nd), the other 2 work as expected. Given that this works for RC6, I'm looking at commits since then, to see if anything from there is causing this. Any hints on what should I do to check is my system affecting this somehow? I'm using the test instructions you posted on codepad some time ago. Thanks! [2012-01-29 13:50:42] ras...@php.net I am not seeing these failures here. Could you dig into one of them to see if you can figure out why it is failing for you? ------------ [2012-01-29 12:20:21] robertbasic dot com at gmail dot com Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923&edit=1 ID: 60923 Comment by: robertbasic dot com at gmail dot com Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli Status: Closed Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Assigned To:mike Block user comment: N Private report: N New Comment: Just tested again with this fix/commit, the tests pass again! Thanks! Previous Comments: [2012-01-30 12:20:05] m...@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-01-30 12:17:49] m...@php.net Automatic comment from SVN on behalf of mike Revision: http://svn.php.net/viewvc/?view=revision&revision=322931 Log: use stderr before, stdout after php_output_startup() and sapi_module.ub_write() after php_output_activate() - fixes Bug #60920 CLI: php -v on STDERR - fixes Bug #60923 Failing tests for sapi/cli [2012-01-29 19:05:18] ras...@php.net Yeah, looks to be the same as bug #60920 [2012-01-29 17:39:06] robertbasic dot com at gmail dot com Think I narrowed it down even more. Seems to me the problem is in the new php_output_stderr function - when I comment it out, the tests pass again. I'll attach a diff to show what I did. [2012-01-29 16:21:26] robertbasic dot com at gmail dot com Hello again! I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through those commits. What I've managed to do so far is to find what commit is causing the tests to fail (at least I think it's this one): http://svn.php.net/viewvc?view=revision&revision=322743 The r322743 of the code has the tests failing, while the one prior to it (r322678) has the tests passing. Sadly my C skills are almost non-existent, so I can't promise a patch, but will continue to poke around it. 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=60923 -- Edit this bug report at https://bugs.php.net/bug.php?id=60923&edit=1
Bug #53929 [Com]: no-temporary name for a uploaded file
Edit report at https://bugs.php.net/bug.php?id=53929&edit=1 ID: 53929 Comment by: robertbasic dot com at gmail dot com Reported by:dungar at kabia dot fr Summary:no-temporary name for a uploaded file Status: Not a bug Type: Bug Package:Filesystem function related Operating System: debian PHP Version:5.3.5 Block user comment: N Private report: N New Comment: This is not a PHP bug, but improper usage of the Zend_File_Transfer component from Zend Framework. In the manual, http://framework.zend.com/manual/en/zend.file.transfer.introduction.html#zend.file.transfer.introduction.informations there's a clear big warning stating that "due to security reasons also the original data within $_FILES will be overridden as soon as Zend_File_Transfer is initiated." Previous Comments: [2012-02-24 19:37:55] s...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please review the user comments and reopen if you still consider this a problem. [2011-07-31 19:55:13] mf_peppa at yahoo dot com oops, my bad - there is no problem with PHP, it's just a programming error - the guy who submitted this bug calls $fFile = $oForms_File->getValue('file'), which includes a move_uploaded_file() call... that's why the test results are wrong... i would recommend closing this bug [2011-07-31 18:53:09] mf_peppa at yahoo dot com same problem (mac os lion, php 5.3.6) [2011-02-04 19:25:09] dungar at kabia dot fr Description: The function :is_uploaded_file return every time false. (for a classical upload) For find the file i must edit the path : $file['file']['tmp_name'] by this path : dirname($file['file']['tmp_name']).'/'.$file['file']['name'] The file of the tmp_name wasn't changed, and the uploaded name is used. (May be dangerous for include attack ?) Test script: --- $oForms_File = new Forms_File(); if ( $oForms_File->isValid($_POST) ) { $fFile = $oForms_File->getValue('file'); $adapter = new Zend_File_Transfer_Adapter_Http(); $adapter->setDestination(CORE_APP_DIR.DS.'modules'.DS.'bugtracking'.DS.'files','test.todel'); ; $file = $adapter->getFileInfo('file'); echo file_get_contents(dirname($file['file']['tmp_name']).'/'.$file['file']['name']);exit; test($file); test($_FILES); test( is_uploaded_file($_FILES['file']['tmp_name']) ); test($adapter->receive()); test($adapter->getMessages()); function ScanDirectory($Directory){ $MyDirectory = opendir($Directory) or die('Erreur'); while($Entry = @readdir($MyDirectory)) { if(is_dir($Directory.'/'.$Entry)&& $Entry != '.' && $Entry != '..') { echo ''.$Directory; ScanDirectory($Directory.'/'.$Entry); echo ''; } else { echo ''.$Entry.''; } } closedir($MyDirectory); } ScanDirectory('/webdata/n/q/7a8fwoym65pts9/vbi3und15xa44wgw/php_upload'); setName('file'); /* $this->setAction($this->view->url( array( 'module'=> Zend_Controller_Front::getInstance()->getRequest()->getParam('module'), 'controller'=> 'files', 'action'=> 'upload', 'id'=> Zend_Controller_Front::getInstance()->getRequest()->getParam('id'), ), $this->routes['crud-action-controller-id'], true) );
Bug #54155 [Com]: Insufficient+Inconsistent error reporting
Edit report at https://bugs.php.net/bug.php?id=54155&edit=1 ID: 54155 Comment by: robertbasic dot com at gmail dot com Reported by:a1283465 at jnxjn dot com Summary:Insufficient+Inconsistent error reporting Status: Open Type: Bug Package:Variables related Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I'd argue that one should check that a variable is of an expected type, or maybe cast the type to the expected one, before using it. I vote for "Not a bug". Previous Comments: [2011-03-03 23:23:32] a1283465 at jnxjn dot com Description: If you try to access an undefined index on an array, you will get an error. But if you try the same on bool(false) PHP will silently accept it and ignores the error. Please note that this is especially dangerous on database results, where you get false instead of an array when there is no result. If you try the same on a valid array with an invalid index you will get a E_NOTICE. So trying to use the array operator on a non-array should at least raise an E_STRICT error, indicating that there is a problem, instead of silently continuing to use the wrong result for further calculations. Test script: --- $array1 = false; $array2 = array('a'=>3); echo 5+3*$array1['a']; // output: 5 var_dump($array1['b']); // output: NULL var_dump($array2['b']); // output: Notice: Undefined index: b -- Edit this bug report at https://bugs.php.net/bug.php?id=54155&edit=1
Bug #53823 [Com]: preg_replace: * qualifier on unicode replace garbles the string
Edit report at https://bugs.php.net/bug.php?id=53823&edit=1 ID: 53823 Comment by: robertbasic dot com at gmail dot com Reported by:keith at chaos-realm dot net Summary:preg_replace: * qualifier on unicode replace garbles the string Status: Verified Type: Bug Package:PCRE related Operating System: Linux PHP Version:5.3SVN-2011-01-23 (snap) Block user comment: N Private report: N New Comment: I tried my best on this one. Tested against the trunk: svn info | grep Revision Revision: 323476 I created a test file for this, will attach. I ran the following with gdb: $ gdb sapi/cgi/php-cgi and then set a breakpoint (gdb) break php_pcre.c:1318 finally ran the test script like: (gdb) run run-tests.php ext/pcre/tests/bug53823.phpt On https://gist.github.com/1904467 I c/p-ed some output from gdb, but that might be incorrect as I'm fairly new to all this. Anyway, lines 12 and 22 in that gist caught my attention. Also, I think the same issue exists for preg_filter, too. Previous Comments: [2011-01-26 08:02:54] ahar...@php.net Verified on 5.3 and trunk. [2011-01-23 18:10:44] tino dot didriksen at gmail dot com ...and then I forget to change the *. Let's try that again... These work as expected: echo preg_replace('/[^\pL\pM]+/iu', '', 'áéÃóú'); echo preg_replace('/[^\pL\pM\pN]+/iu', '', 'áéÃóú'); [2011-01-23 18:09:23] tino dot didriksen at gmail dot com A workaround is to use + instead of *. These work as expected: echo preg_replace('/[^\pL\pM]*/iu', '', 'áéÃóú'); echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéÃóú'); [2011-01-23 18:04:49] keith at chaos-realm dot net . [2011-01-23 18:00:57] keith at chaos-realm dot net Description: When using the following test script to strip out all unicode except for letters the string becomes garbled when the * qualifier is added, the only surviving character that is intact is ú. Also, if you add \pN to the exceptions it additionally preserves the ó. Verified on 5.2,5.3 and 5.3-SNAP. Test script: --- echo preg_replace('/[^\pL\pM]*/iu', '', 'áéÃóú'); or echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéÃóú'); Expected result: áéÃóú Actual result: -- ����ú or ���óú (if \pN is added to the exceptions). -- Edit this bug report at https://bugs.php.net/bug.php?id=53823&edit=1
Bug #53823 [Com]: preg_replace: * qualifier on unicode replace garbles the string
Edit report at https://bugs.php.net/bug.php?id=53823&edit=1 ID: 53823 Comment by: robertbasic dot com at gmail dot com Reported by:keith at chaos-realm dot net Summary:preg_replace: * qualifier on unicode replace garbles the string Status: Verified Type: Bug Package:PCRE related Operating System: Linux PHP Version:5.3SVN-2011-01-23 (snap) Block user comment: N Private report: N New Comment: Updated the test case showing that preg_filter and preg_replace_callback are affected, too. Previous Comments: [2012-02-24 23:33:34] robertbasic dot com at gmail dot com I tried my best on this one. Tested against the trunk: svn info | grep Revision Revision: 323476 I created a test file for this, will attach. I ran the following with gdb: $ gdb sapi/cgi/php-cgi and then set a breakpoint (gdb) break php_pcre.c:1318 finally ran the test script like: (gdb) run run-tests.php ext/pcre/tests/bug53823.phpt On https://gist.github.com/1904467 I c/p-ed some output from gdb, but that might be incorrect as I'm fairly new to all this. Anyway, lines 12 and 22 in that gist caught my attention. Also, I think the same issue exists for preg_filter, too. [2011-01-26 08:02:54] ahar...@php.net Verified on 5.3 and trunk. [2011-01-23 18:10:44] tino dot didriksen at gmail dot com ...and then I forget to change the *. Let's try that again... These work as expected: echo preg_replace('/[^\pL\pM]+/iu', '', 'áéÃóú'); echo preg_replace('/[^\pL\pM\pN]+/iu', '', 'áéÃóú'); [2011-01-23 18:09:23] tino dot didriksen at gmail dot com A workaround is to use + instead of *. These work as expected: echo preg_replace('/[^\pL\pM]*/iu', '', 'áéÃóú'); echo preg_replace('/[^\pL\pM\pN]*/iu', '', 'áéÃóú'); [2011-01-23 18:04:49] keith at chaos-realm dot net . 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=53823 -- Edit this bug report at https://bugs.php.net/bug.php?id=53823&edit=1