[PHP-BUG] Bug #63893 [NEW]: poor efficiency of strtr() using array with keys of very different length
From: scope at planetavent dot de Operating system: Windows Server 2008 / RHEL 6.3 PHP version: 5.4.10 Package: Strings related Bug Type: Bug Bug description:poor efficiency of strtr() using array with keys of very different length Description: As the documentation of strtr() points out, strtr "... will be the most efficient when all the keys have the same size". Using keys of very different lengths results in poor performance, even on very small inputs. If the str_repeat() for "m" in the test script is adjusted to 2 the resulting runtime increases to 45 seconds for strtr() while str_replace() does not increase notably. There are cases where the replacement array is built dynamically, so there might be little control over the keylengths. It's easy to expand the example such that strtr() takes several hours compared to just a few seconds using str_replace(). Test script: --- 'b', $long_from_x => 'y' ); $start = microtime( true ); $result_1 = strtr( $text, $replacements ); echo "strtr: " . number_format( microtime( true ) - $start, 4 ) . "\n"; $start = microtime( true ); $result_2 = str_replace( array_keys( $replacements ), array_values( $replacements ), $text ); echo "str_replace: " . number_format( microtime( true ) - $start, 4 ) . "\n"; echo $result_1 === $result_2 ? "results match!\n": "no match!\n"; Expected result: strtr: 0.0001 str_replace: 0.0001 results match! Actual result: -- strtr: 2.4203 str_replace: 0.0001 results match! -- Edit bug report at https://bugs.php.net/bug.php?id=63893&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63893&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63893&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63893&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63893&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63893&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63893&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63893&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63893&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63893&r=support Expected behavior: https://bugs.php.net/fix.php?id=63893&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63893&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63893&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63893&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63893&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63893&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63893&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63893&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63893&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63893&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63893&r=mysqlcfg
[PHP-BUG] Bug #63240 [NEW]: stream_get_line return contains delimiter string
From: scope at planetavent dot de Operating system: Windows Server 2008 / RHEL 6.2 PHP version: 5.3.17 Package: Streams related Bug Type: Bug Bug description:stream_get_line return contains delimiter string Description: On specific file input stream_get_line returns a "line" that actually contains the delimiter. PHP 5.3.10 does not show this problem, PHP versions from 5.3.11 to 5.3.17 do. PHP 5.4.7 seems to be affected as well. Bug #44607 seems to be related, but was fixed long time ago. Test script: --- https://bugs.php.net/bug.php?id=63240&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63240&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63240&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63240&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63240&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63240&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63240&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63240&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63240&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63240&r=support Expected behavior: https://bugs.php.net/fix.php?id=63240&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63240&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63240&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63240&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63240&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63240&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63240&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63240&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63240&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63240&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63240&r=mysqlcfg
[PHP-BUG] Bug #55459 [NEW]: Unable to differentiate between end of file or read error
From: Operating system: Ubuntu 10.04 LTS PHP version: 5.3.7 Package: XML Reader Bug Type: Bug Bug description:Unable to differentiate between end of file or read error Description: We were forced into using xmlreader the other day due to xml file sizes. Usually we use DOM to check for well-formedness and schema validity. It seems, that it is currently not possible to differentiate between a reading error (e.g. not well formed) and "end of file" using xmlreader. Unfortunately it is not possible to call XMLReader::isValid() after an unsuccessful read when using a schema. Of course, if the document is not well-formed it can't be valid. But isValid() just calls onto xmlTextReaderIsValid() which seems to work only, if the node pointer was able to advance correctly (which is not the case for that kind of error). So this is not an option. >From ext/xmlreader/php_xmlreader.c:806 retval = xmlTextReaderRead(intern->ptr); if (retval == -1) { php_error_docref(NULL TSRMLS_CC, E_WARNING, "An Error Occured while reading"); RETURN_FALSE; } else { RETURN_BOOL(retval); } and >From ext/xmlreader/php_xmlreader.c:849 if (retval == -1) { php_error_docref(NULL TSRMLS_CC, E_WARNING, "An Error Occured while reading"); RETURN_FALSE; } else { RETURN_BOOL(retval); } According to libxml, the result of xmlTextReaderRead() is "1 if the node was read successfully, 0 if there is no more nodes to read, or -1 in case of error". Therefor PHP should return true, int(0) or false to be able to check for reading errors. I'm not quite sure if this can be considered a bug. To my mind it is, because it prevents me from using xmlreader in a proper way and as a result, renders it very difficult to work on huge xml files. libxml is able to distinguish between both conditions, so should php. Test script: --- open( $file ); while ( true ) { $success = $xr->read(); if ( !$success ) { # end of file or error? var_dump( $success ); echo "no success\n"; break; } else { echo "read success\n"; } } Expected result: Ability to check for int(0) = no elements to read and false = error during read. Actual result: -- [...] read success read success read success Warning: XMLReader::read(): An Error Occured while reading in X:\xmlreader.php on line 12 bool(false) no success -- Edit bug report at https://bugs.php.net/bug.php?id=55459&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55459&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55459&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55459&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55459&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55459&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55459&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55459&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55459&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55459&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55459&r=support Expected behavior: https://bugs.php.net/fix.php?id=55459&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55459&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55459&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55459&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55459&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55459&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55459&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55459&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55459&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55459&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55459&r=mysqlcfg
#50732 [Opn]: exec() adds single byte twice to $output array
ID: 50732 User updated by: scope at planetavent dot de Reported By: scope at planetavent dot de Status: Open Bug Type: Program Execution Operating System: Linux, Windows PHP Version: 5.3.1 New Comment: Of course, this applies as well to output that just ends with a newline followed by a single byte. Example: #!/bin/sh echo "Hello\nWorl\nd" results in: Array ( [0] => Hello [1] => Worl [2] => d [3] => d ) Previous Comments: [2010-01-12 19:29:26] scope at planetavent dot de Description: If exec is used to start a command that outputs only a single byte, and if the $output array is used, the byte is added twice to the output array. Tested with php 5.3.1 in cli mode on Windows 2003 Server and Ubuntu 9.10 Server. This behaviour was introduced with bugfix to #49847: >From exec.c:125 while (php_stream_get_line(stream, b, EXEC_INPUT_BUF, &bufl)) { ... if (b[bufl - 1] != '\n' && !php_stream_eof(stream)) { ... continue; If only a single byte is read, php_stream_eof(stream) returns true, thus no second loop will take place. After line 149: while (l-- && isspace(((unsigned char *)buf)[l])); buflen is 1 and l is 0, therefor line 160: if ((type == 2 && bufl && !l) || type != 2) { yields true and the buffer is added to the output array, again. Reproduce code: --- x ) Actual result: -- Array ( [0] => x [1] => x ) -- Edit this bug report at http://bugs.php.net/?id=50732&edit=1
#50732 [NEW]: exec() adds single byte twice to $output array
From: scope at planetavent dot de Operating system: Linux, Windows PHP version: 5.3.1 PHP Bug Type: Program Execution Bug description: exec() adds single byte twice to $output array Description: If exec is used to start a command that outputs only a single byte, and if the $output array is used, the byte is added twice to the output array. Tested with php 5.3.1 in cli mode on Windows 2003 Server and Ubuntu 9.10 Server. This behaviour was introduced with bugfix to #49847: >From exec.c:125 while (php_stream_get_line(stream, b, EXEC_INPUT_BUF, &bufl)) { ... if (b[bufl - 1] != '\n' && !php_stream_eof(stream)) { ... continue; If only a single byte is read, php_stream_eof(stream) returns true, thus no second loop will take place. After line 149: while (l-- && isspace(((unsigned char *)buf)[l])); buflen is 1 and l is 0, therefor line 160: if ((type == 2 && bufl && !l) || type != 2) { yields true and the buffer is added to the output array, again. Reproduce code: --- x ) Actual result: -- Array ( [0] => x [1] => x ) -- Edit bug report at http://bugs.php.net/?id=50732&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50732&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50732&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50732&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50732&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50732&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50732&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50732&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50732&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50732&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50732&r=support Expected behavior: http://bugs.php.net/fix.php?id=50732&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50732&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50732&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50732&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50732&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50732&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50732&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50732&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50732&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50732&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50732&r=mysqlcfg
#47811 [Com]: preg_match that can cause segmentation fault
ID: 47811 Comment by: scope at planetavent dot de Reported By: travis at wikihow dot com Status: Open Bug Type: Reproducible crash Operating System: CentOS release 4.4 & Mac OS 10.4 PHP Version: 5.2.9 New Comment: Here's another snippet: This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1 on windows 2003. Previous Comments: [2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net I have a similar segfault testcase for preg_match. It always crashes at a stringlength of around 6700. PHP is 5.2.8 on gentoo linux. # Create my test-string for ($i=0; $i<2; $i++) { $string .= 'a'; } # The pattern matches for \\, \", everything except " and " $pattern = '/^(|\\"|[^"]|")+$/'; print "Trying with string length " . "\033" . '[s'; for ($counter=6600; $counter@im', $text, $matches); Reproduce code: --- http://wikidiy.com/php_bug_crash.txt Expected result: Apache not supposed to crash, completes preg_match, dumps $matches array. Actual result: -- Apache seg faults [Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=47811&edit=1
#38604 [Com]: Memory leak in SimpleXML ?
ID: 38604 Comment by: scope at planetavent dot de Reported By: apachephp at gmail dot com Status: Open Bug Type: SimpleXML related Operating System: Linux PHP Version: 5.1.5 New Comment: Hi! A shorter version that quickly eats up all the memory: '; $xmldata = simplexml_load_string( $xml ); while( true ) { foreach ( $xmldata->node as $node ) { } } ?> (php5.1.5, WinXP, Shell) Also tried the latest snapshot, same effect. Previous Comments: [2006-09-19 09:26:17] rolfdw at gmail dot com I dont know if this will help anyone but I found that it is the foreach that actually causes the memory leak. If you replace the FOREACH with a FOR loop it seems to be stable. [2006-08-28 09:48:31] apachephp at gmail dot com script: 6809586b1c38100f 4323ac020 NULL 4323ac04e ihttp://www.mysqlperformanceblog.com/ Who AM I 0232343d3062 204923 http://www.mysqlperformanceblog.com/ http://www.mysqlperformanceblog.com/ Apachephp 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. 0 2006-08-22 23:19:43 Qwerrt 1 http://www.mysqlperformanceblog.com/ http://www.mysqlperformanceblog.com/ 1 918180 MySQL Performance tuning optimization consulting Simple XML 0 0 1 '; function ProcessFile($filename) { global $XML; $xml = simplexml_load_string($XML); echo "Memory: ".memory_get_usage() . "\n"; foreach ($xml->report as $reports) { //echo $reports->forumid."\n"; } // var_dump($xml); unset($xml); } while(true) { ProcessFile($file); echo "Loop ".($i++).", memory used: ".memory_get_usage() . "\n"; } ?> output: Loop 1, memory used: 57844 ... Loop 1000, memory used: 269632 .. Loop 5000, memory used: 1461740 .. Loop 1, memory used: 2914996 Loop 65531, memory used: 17047104 Memory: 17047104 Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3145728 bytes) in /mnt/data/home/vadim/testfeed/testxml2.php on line 57 [2006-08-28 08:49:54] [EMAIL PROTECTED] 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. [2006-08-28 08:46:08] apachephp at gmail dot com Well, I don't have XML files with 10 bytes, and with 10Mb files my memory is exhausted after processing 20 files. Memory is OK if I am processing files one per run. [2006-08-28 08:09:05] [EMAIL PROTECTED] I don't think you really need 10Mb file to reproduce it. If it really leaks, then it should do it even with 10 bytes XML file. 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 http://bugs.php.net/38604 -- Edit this bug report at http://bugs.php.net/?id=38604&edit=1