#48426 [NEW]: PDO::exec() never modifies
From: jengert at gmail dot com Operating system: OS X 10.5 PHP version: 5.2.9 PHP Bug Type: Apache2 related Bug description: PDO::exec() never modifies Description: my table looks like this CREATE TABLE `volunteer` ( `volunteer_id` integer PRIMARY KEY, `origin_id` int(10) NOT NULL, `name` varchar(200) NOT NULL, UNIQUE (`name`) ); Works via command line, not through apache (with and w/o entropy) Reproduce code: --- $db = new PDO('sqlite:mealdata.sqlite'); $querystring = "INSERT INTO `volunteer` (`origin_id` , `name`) VALUES (3, 'my name')"; $query = $db->exec($querystring); echo $query; Expected result: 1 Actual result: -- 0 -- Edit bug report at http://bugs.php.net/?id=48426&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48426&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48426&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48426&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48426&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48426&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48426&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48426&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48426&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48426&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48426&r=support Expected behavior: http://bugs.php.net/fix.php?id=48426&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48426&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48426&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48426&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48426&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48426&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48426&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48426&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48426&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48426&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48426&r=mysqlcfg
#48425 [NEW]: Can not call static methods from .net DLL
From: halflife at cableone dot net Operating system: Windows Server 2003 PHP version: 5.2.9 PHP Bug Type: COM related Bug description: Can not call static methods from .net DLL Description: I can call any public methods in a public class from my dll no problem, but calling any methods that are set as static, results in the error Fatal error: Call to undefined method com::DoMD5() in C:\wamp\www\xxx\netphp.php on line 5 Reproduce code: --- Source to dll class http://www.dlgnetworks.com/HashPotato.cs PHP Code calling it $DLGtb = new COM("DLG.Crypto.HashPotato"); echo $DLGtb->DoMD5("test"); Expected result: Should return the MD5 of the string Actual result: -- Fatal error: Call to undefined method com::DoMD5() -- Edit bug report at http://bugs.php.net/?id=48425&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48425&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48425&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48425&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48425&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48425&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48425&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48425&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48425&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48425&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48425&r=support Expected behavior: http://bugs.php.net/fix.php?id=48425&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48425&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48425&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48425&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48425&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48425&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48425&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48425&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48425&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48425&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48425&r=mysqlcfg
#48424 [NEW]: strtotime changes year to current year with date formatted "17 July, 2004"
From: php at qrs dot oib dot com Operating system: Windows XP, Linux PHP version: 5.2.9 PHP Bug Type: Date/time related Bug description: strtotime changes year to current year with date formatted "17 July, 2004" Description: strtotime changes the year to the current year with a date formatted like "17 July, 2004". Reproduce code: --- print strftime("%d %B, %Y", strtotime("July 17, 2004")); print strftime("%d %B, %Y", strtotime("17 July, 2004")); // <--- print strftime("%d %B, %Y", strtotime("17 July 2004")); Expected result: 17 July, 2004 17 July, 2004 17 July, 2004 Actual result: -- 17 July, 2004 17 July, 2009 17 July, 2004 -- Edit bug report at http://bugs.php.net/?id=48424&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48424&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48424&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48424&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48424&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48424&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48424&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48424&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48424&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48424&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48424&r=support Expected behavior: http://bugs.php.net/fix.php?id=48424&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48424&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48424&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48424&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48424&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48424&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48424&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48424&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48424&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48424&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48424&r=mysqlcfg
#48423 [NEW]: ksort applied with array_walk not working consistently
From: brad at njoe dot com Operating system: Windows & *nix PHP version: 5.2.9 PHP Bug Type: Arrays related Bug description: ksort applied with array_walk not working consistently Description: While using array_walk() to apply ksort() to a multidimensional array, I experienced some unusual results. I expected that since each "sub-array" contained identical keys and values that they would all be sorted in the same manner. See the example code/expected output below for more information. I've tried this on Windows (ver. 5.2.9-2) as well as a Linux box (ver. 5.2.6) and both yielded the same results. If I manually "walk" ksort() through the array, i.e.: ksort($test[0]); ksort($test[1]); ksort($test[2]); ksort($test[3]); ksort($test[4]); ksort($test[5]); then the results are as expected. I've tried with varying number of array elements in the parent array as well as changing the keys around; no matter what I did, the array in $test[1] was always sorted incorrectly (and unpredictably at that). Reproduce code: --- 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6'), array('key' => 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6'), array('key' => 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6'), array('key' => 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6'), array('key' => 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6'), array('key' => 'value1', 'this' => 'value2', 'word' => 'value3', 'blah' => 'value4', 'foo' => 'value5', 'bar' => 'value6') ); array_walk($test, 'ksort'); print_r($test); ?> Expected result: Array ( [0] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [1] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [2] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [3] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [4] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [5] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) ) Actual result: -- Array ( [0] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [1] => Array ( [foo] => value5 [bar] => value6 [blah] => value4 [word] => value3 [this] => value2 [key] => value1 ) [2] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [3] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [4] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) [5] => Array ( [bar] => value6 [blah] => value4 [foo] => value5 [key] => value1 [this] => value2 [word] => value3 ) ) -- Edit bug report at http://bugs.php.net/?id=48423&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48423&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48423&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48423&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48423&r=fixedcvs Fixed in CVS and need be documented: ht
#48416 [Csd]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr Status: Closed Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: Fixed in 5.2 as well now. Previous Comments: [2009-05-28 21:58:10] scott...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Added a LRU and a cache limit to the ereg code for 5.3. Give it a few hours and grab another 5.3 snapshot, not sure about fixing this in 5.2. Will check with ilia. [2009-05-28 18:17:49] bmorel at ssi dot fr Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48422 [Opn->Bgs]: Math sum error
ID: 48422 Updated by: ras...@php.net Reported By: fernandokts at msn dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 5.2.9 New Comment: You have discovered octal numbers. Not a bug. Previous Comments: [2009-05-28 22:44:37] fernandokts at msn dot com Description: When doing simple math, there is a problem with numbers with 2 digits greater then 07 in sums. It appears to ignore any numbers starting with a zero that are bigger then 07. Reproduce code: --- Expected result: The result is: 30 Actual result: -- The result is: 22 -- Edit this bug report at http://bugs.php.net/?id=48422&edit=1
#48422 [NEW]: Math sum error
From: fernandokts at msn dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Math related Bug description: Math sum error Description: When doing simple math, there is a problem with numbers with 2 digits greater then 07 in sums. It appears to ignore any numbers starting with a zero that are bigger then 07. Reproduce code: --- Expected result: The result is: 30 Actual result: -- The result is: 22 -- Edit bug report at http://bugs.php.net/?id=48422&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48422&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48422&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48422&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48422&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48422&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48422&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48422&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48422&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48422&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48422&r=support Expected behavior: http://bugs.php.net/fix.php?id=48422&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48422&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48422&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48422&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48422&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48422&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48422&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48422&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48422&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48422&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48422&r=mysqlcfg
#48421 [NEW]: stream_get_line() - allow $length to be optional
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: stream_get_line() - allow $length to be optional Description: I believe stream_get_line() should allow the $length parameter to be optional by allowing a $length of -1 that would read the remaining buffer up to either the $ending delimiter or EOF. Currently if you pass a $length of 0, the $length defaults to PHP_SOCK_CHUNK_SIZE (8192) in ext/standard/streamsfuncs.c. If you pass a length of -1, a PHP Warning is generated. Other 'similar' functions that allow length to be optional or -1 are fgets, stream_get_contents, and file_get_contents. Also, the manual page for stream_get_line() states that this function is the same fgets() except for the handling of the delimiter - but another difference, at least right now, is that the $length parameter is required in stream_get_line(), but optional in fgets(). Reproduce code: --- http://bugs.php.net/?id=48421&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48421&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48421&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48421&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48421&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48421&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48421&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48421&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48421&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48421&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48421&r=support Expected behavior: http://bugs.php.net/fix.php?id=48421&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48421&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48421&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48421&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48421&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48421&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48421&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48421&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48421&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48421&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48421&r=mysqlcfg
#48420 [NEW]: stream_get_line() - invalid result when passing $length and $ending
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Streams related Bug description: stream_get_line() - invalid result when passing $length and $ending Description: When you pass to stream_get_line() a $length that is greater than the file size and a $ending that does not appear in the file, stream_get_line() returns bool(false) rather than the string that is in your file. In the below example, when I run stream_get_line() passing in a $length of 6 and a $ending of "\n", stream_get_line() returns false rather than the contents of the file. The manual states "Reading ends when length bytes have been read, when the string specified by ending is found (which is not included in the return value), or on EOF (whichever comes first).", so I believe the contents of my file should be returned since EOF is first to be reached. Reproduce code: --- http://bugs.php.net/?id=48420&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48420&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48420&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48420&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48420&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48420&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48420&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48420&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48420&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48420&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48420&r=support Expected behavior: http://bugs.php.net/fix.php?id=48420&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48420&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48420&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48420&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48420&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48420&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48420&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48420&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48420&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48420&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48420&r=mysqlcfg
#48416 [Fbk->Csd]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr -Status: Feedback +Status: Closed Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Added a LRU and a cache limit to the ereg code for 5.3. Give it a few hours and grab another 5.3 snapshot, not sure about fixing this in 5.2. Will check with ilia. Previous Comments: [2009-05-28 18:17:49] bmorel at ssi dot fr Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48419 [NEW]: non-portable CGI code (Empty POST data)
From: juro at shaw dot ca Operating system: Windows XP PHP version: 5.2.10RC1 PHP Bug Type: CGI related Bug description: non-portable CGI code (Empty POST data) Description: Using a generic web server with a simple CGI support (running on Windows XP), I fail to obtain any $_POST data. However, raw post data are OK. Raw post data is sent to the PHP-CGI.exe via redirected pipe handle. PHP-CGI reads correctly posted raw data using stdin. I suspect the culprit may be with the following PHP source code: File:cgi_main.c Routine:static int sapi_cgi_read_post(char *buffer, uint count_bytes TSRMLS_DC) ... tmp_read_bytes = read(0, buffer + read_bytes, count_bytes - read_bytes); ... Low level i/o functions read,write,open are not 100% portable. The code is most like meant to read stdin. Assuming that file descriptor for stdin is numerically equal to 0 on all platforms is wrong. The code should be probably something like this tmp_read_bytes = read(_fileno(stdin), buffer + read_bytes, count_bytes - read_bytes); -- Edit bug report at http://bugs.php.net/?id=48419&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48419&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48419&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48419&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48419&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48419&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48419&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48419&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48419&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48419&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48419&r=support Expected behavior: http://bugs.php.net/fix.php?id=48419&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48419&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48419&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48419&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48419&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48419&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48419&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48419&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48419&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48419&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48419&r=mysqlcfg
#48418 [Com]: NaN > NaN, NaN > 0, NaN < 0 return true
ID: 48418 Comment by: phplists at stanvassilev dot com Reported By: phplists at stanvassilev dot com Status: Open Bug Type: Math related Operating System: Linux, BSD, possibly all *nix PHP Version: 5.2.9 New Comment: And to add a note: $NaN >= $NaN $NaN >= 0 $NaN <= 0 These also return true and must return false. Previous Comments: [2009-05-28 18:57:57] phplists at stanvassilev dot com Description: Tested on Gentoo, CentOS, OSX. This is possibly NOT related to the Windows NaN bug, as Windows is NOT affected by this issue. However, please test if any fix doesn't cause regression on Windows. NaN > NaN, NaN > 0, NaN < 0 return true, while they should return false in all cases (any comparison where either side is NaN, should return false). Reproduce code: --- $NaN = sqrt(-1); var_dump($NaN > $NaN); var_dump($NaN > 0); var_dump($NaN < 0); Expected result: float(NAN) bool(false) bool(false) bool(false) Actual result: -- float(NAN) bool(true) bool(true) bool(true) -- Edit this bug report at http://bugs.php.net/?id=48418&edit=1
#48418 [NEW]: NaN > NaN, NaN > 0, NaN < 0 return true
From: phplists at stanvassilev dot com Operating system: Linux, BSD, possibly all *nix PHP version: 5.2.9 PHP Bug Type: Math related Bug description: NaN > NaN, NaN > 0, NaN < 0 return true Description: Tested on Gentoo, CentOS, OSX. This is possibly NOT related to the Windows NaN bug, as Windows is NOT affected by this issue. However, please test if any fix doesn't cause regression on Windows. NaN > NaN, NaN > 0, NaN < 0 return true, while they should return false in all cases (any comparison where either side is NaN, should return false). Reproduce code: --- $NaN = sqrt(-1); var_dump($NaN > $NaN); var_dump($NaN > 0); var_dump($NaN < 0); Expected result: float(NAN) bool(false) bool(false) bool(false) Actual result: -- float(NAN) bool(true) bool(true) bool(true) -- Edit bug report at http://bugs.php.net/?id=48418&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48418&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48418&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48418&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48418&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48418&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48418&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48418&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48418&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48418&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48418&r=support Expected behavior: http://bugs.php.net/fix.php?id=48418&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48418&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48418&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48418&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48418&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48418&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48418&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48418&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48418&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48418&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48418&r=mysqlcfg
#48365 [Opn]: glob() function returns empty array
ID: 48365 User updated by: peter dot chen at itg dot com Reported By: peter dot chen at itg dot com Status: Open Bug Type: Apache2 related Operating System: sparc-sol2.10 PHP Version: 5.2.9 New Comment: Oh yeah, and the command returns: bool(false) Previous Comments: [2009-05-28 18:42:33] peter dot chen at itg dot com I'm using sparc-solaris2.10. Was there a flag I needed to include for my php install to enable glob() to work? [2009-05-28 16:50:31] j...@php.net Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/*"));' [2009-05-28 16:49:23] j...@php.net Exactly what Solaris version are you on? Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/"));' [2009-05-27 23:05:14] peter dot chen at itg dot com My apologies, I did not read all the instructions. Is there a flag I needed to enable when building php? As for the code, I mistakenly left the ';' that caused the parse error. The code should be as follows: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*')); print("***"); print("scandir:"); print_r(scandir($path)); ?> [2009-05-23 17:03:08] j...@php.net You obviously didn't follow the url provided in the email. Please, do not "Add Comment" to your own report, use the "Edit Submission" (where the link in the email points too. And now, please provide the code that actually causes the problem. That code works fine everywhere. 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/48365 -- Edit this bug report at http://bugs.php.net/?id=48365&edit=1
#48410 [Opn->Bgs]: Using database link throws unrecognized date warning
ID: 48410 Updated by: s...@php.net Reported By: krastin dot georgiev at gmail dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Linux (ALL) PHP Version: 5.2.9 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. - The error message is from the communication between the source and destination databases of the DB link, so PHP OCI8 is unlikely to be the issue. Check the query in SQL*Plus (make sure SQL*Plus use the same Oracle environment settings as the Apache/PHP process). Check the ORA_NLSxx environment variables in effect for the shells starting the DBs were correct. See metalink.oracle.com Note 236320.1 and Note 338832.1 Before updating this bug, follow up on an Oracle-specific forum or with Oracle Support. Previous Comments: [2009-05-27 23:07:05] krastin dot georgiev at gmail dot com As sample a table named TY can be created with the following two columns: TY_ID INTEGER TY_NM VARCHAR2(4000) Querying this table across a link will cause the warning. [2009-05-27 23:00:58] krastin dot georgiev at gmail dot com Description: When doing a call across a database link Oracle throws a warning immediately. Compiled using different versions of Oracle instant client and OCI versions. Instant Client versions: 10.2.0.3 10.2.0.4 11.1.0.7.0 OCI versions: 1.2.5 1.3.4 1.3.5 It is important to note that using 1.2.5 on Windows (precompiled) does NOT cause this warning. This is only a problem under Linux. Reproduce code: --- "; } } // end if OCILogoff($conn); ?> Expected result: Warning: oci_execute() [function.oci-execute]: ORA-01821: date format not recognized ORA-02063: preceding line from MUREXDM in /home/myself/proc.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=48410&edit=1
#48365 [Fbk->Opn]: glob() function returns empty array
ID: 48365 User updated by: peter dot chen at itg dot com Reported By: peter dot chen at itg dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: sparc-sol2.10 PHP Version: 5.2.9 New Comment: I'm using sparc-solaris2.10. Was there a flag I needed to include for my php install to enable glob() to work? Previous Comments: [2009-05-28 16:50:31] j...@php.net Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/*"));' [2009-05-28 16:49:23] j...@php.net Exactly what Solaris version are you on? Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/"));' [2009-05-27 23:05:14] peter dot chen at itg dot com My apologies, I did not read all the instructions. Is there a flag I needed to enable when building php? As for the code, I mistakenly left the ';' that caused the parse error. The code should be as follows: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*')); print("***"); print("scandir:"); print_r(scandir($path)); ?> [2009-05-23 17:03:08] j...@php.net You obviously didn't follow the url provided in the email. Please, do not "Add Comment" to your own report, use the "Edit Submission" (where the link in the email points too. And now, please provide the code that actually causes the problem. That code works fine everywhere. [2009-05-23 10:35:41] carsten_sttgt at gmx dot de > print_r(glob($path . '*.*';)); This line give you a parse error. Must be: | print_r(glob($path . '*.*')); Apart from this, the code is working for me (Win,BSD). BTW: > [0] => . > [1] => .. > [2] => authtest With your code, this can't be part of the result from glob(). Regards, Carsten 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/48365 -- Edit this bug report at http://bugs.php.net/?id=48365&edit=1
#48417 [Bgs]: Missing config.w32.h
ID: 48417 User updated by: php at schubec dot com Reported By: php at schubec dot com Status: Bogus Bug Type: Compile Failure Operating System: Windows PHP Version: 5.3.0RC2 New Comment: Hi! >it is generated at configure time. Okay... thank you. But why was it part of the PHP 5.2.9 sourcecode download then? So the bug is not that it is missing in 5.3.0RC2 but that it was part of 5.2.9, right? Thank you! Previous Comments: [2009-05-28 17:41:36] paj...@php.net it is generated at configure time. [2009-05-28 17:39:51] php at schubec dot com Description: File main/config.w32.h in PHP 5.3.0RC2 is missing. The file is required because Zend/zend_config.w32.h includes it. The missing file causes that PHP cannot be comiled. Compiler: VC6 OS: WindowsXP PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up. Reproduce code: --- Tryp compile PHP under Windows. Expected result: PHP able to compile :-) Actual result: -- PHP unable to compile :-( -- Edit this bug report at http://bugs.php.net/?id=48417&edit=1
#48416 [Com]: Memleak in ereg() and eregi() functions
ID: 48416 Comment by: bmorel at ssi dot fr Reported By: bmorel at ssi dot fr Status: Feedback Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben Previous Comments: [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#45289 [NoF]: Cannot use prepared statements and fetch_row together
ID: 45289 Updated by: u...@php.net Reported By: mike dot benza at rice dot edu Status: No Feedback Bug Type: MySQLi related Operating System: * PHP Version: 5.2.4 New Comment: I think its bogus. Wrong use of the API. The critical part here is that you get a result set at all... Previous Comments: [2009-05-15 19:55:28] jochen dot wiedmann at gmail dot com I have checked the latest snapshot (php5.2-200905151830), whether the problem still persists by using the script below. (Should be easy to derive a .phpt file from it.) real_connect("localhost", "root", null, 'test'); if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row") or die($mysqli->error); $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL PRIMARY KEY, name VARCHAR(64) NOT NULL)") or die($mysqli->error); $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1, 'abc')") or die($mysqli->error); $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE id=?") or die($mysqli->error); $id = "1"; $stmt->bind_param("i", $id) or die($mysqli->error); $stmt->execute() or die($mysqli->error); $result = $mysqli->use_result() or die($mysqli->error); while ($row = $result->fetch_row()) { print "- result row ---\n"; print_r($row); } print "- no more results ---\n"; $mysqli->query("DROP TABLE prep_and_fetch_row") or die($mysqli->error); $mysqli->close(); ?> Expected output: Something like - result row --- Array ( [0] => int(1) [1] => string(3) "abc" ) - no more results --- Actual output: - result row --- Array ( [0] => [1] => ) - no more results --- I'd consider this to be a clear bug. [2009-05-15 13:39:22] jochen dot wiedmann at gmail dot com I have the same problem with PHP 5.2.6, as delivered with Fedora 10 Linux. [2008-07-22 01:00:02] 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-07-14 21:05:49] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-07-11 08:54:43] omolano at PLEASENOSPAMinicia dot es I've also had this problem. In my case I was trying to use PDO::FETCH_ASSOC on a prepared statement and the database was SQLite 3 based. I also got null values, like the above poster, not garbage. 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/45289 -- Edit this bug report at http://bugs.php.net/?id=45289&edit=1
#48417 [Opn->Bgs]: Missing config.w32.h
ID: 48417 Updated by: paj...@php.net Reported By: php at schubec dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Windows PHP Version: 5.3.0RC2 New Comment: it is generated at configure time. Previous Comments: [2009-05-28 17:39:51] php at schubec dot com Description: File main/config.w32.h in PHP 5.3.0RC2 is missing. The file is required because Zend/zend_config.w32.h includes it. The missing file causes that PHP cannot be comiled. Compiler: VC6 OS: WindowsXP PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up. Reproduce code: --- Tryp compile PHP under Windows. Expected result: PHP able to compile :-) Actual result: -- PHP unable to compile :-( -- Edit this bug report at http://bugs.php.net/?id=48417&edit=1
#48417 [NEW]: Missing config.w32.h
From: php at schubec dot com Operating system: Windows PHP version: 5.3.0RC2 PHP Bug Type: Compile Failure Bug description: Missing config.w32.h Description: File main/config.w32.h in PHP 5.3.0RC2 is missing. The file is required because Zend/zend_config.w32.h includes it. The missing file causes that PHP cannot be comiled. Compiler: VC6 OS: WindowsXP PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up. Reproduce code: --- Tryp compile PHP under Windows. Expected result: PHP able to compile :-) Actual result: -- PHP unable to compile :-( -- Edit bug report at http://bugs.php.net/?id=48417&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48417&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48417&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48417&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48417&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48417&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48417&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48417&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48417&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48417&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48417&r=support Expected behavior: http://bugs.php.net/fix.php?id=48417&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48417&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48417&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48417&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48417&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48417&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48417&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48417&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48417&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48417&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48417&r=mysqlcfg
#48416 [Opn->Fbk]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr -Status: Open +Status: Feedback Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. Previous Comments: [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48416 [NEW]: Memleak in ereg() and eregi() functions
From: bmorel at ssi dot fr Operating system: CentOS 5.3 PHP version: 5.2.9 PHP Bug Type: Regexps related Bug description: Memleak in ereg() and eregi() functions Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit bug report at http://bugs.php.net/?id=48416&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48416&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48416&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48416&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48416&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48416&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48416&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48416&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48416&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48416&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48416&r=support Expected behavior: http://bugs.php.net/fix.php?id=48416&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48416&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48416&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48416&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48416&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48416&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48416&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48416&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48416&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48416&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48416&r=mysqlcfg
#48360 [Bgs->Opn]: urlencode and rawurlencode are not RFC-1738 compliant
ID: 48360 Updated by: lbarn...@php.net Reported By: martin2007 at laposte dot net -Status: Bogus +Status: Open Bug Type: URL related Operating System: Linux PHP Version: 5.2.9 Previous Comments: [2009-05-22 11:47:07] lbarn...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. >From the RFC: Usually a URL has the same interpretation when an octet is represented by a character and when it encoded. [...] [...] characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose. This means urlencode() may encode everything, including alphanumerics, and still be RFC1738 compliant. www.example.com/$!*'(), === www.example.com/%24%21%2A%27%28%29%2C www.example.com/%24%21%2A%27%28%29%2C === www.example.com/$!*'(), For your experiment, you may want to try linking twice times the same page, encoded differently. Then check if Google indexes the page twice with two different URLs. Search engines are smart enough to canonicalize every URL they have to work with. Two URLs encoded differently are still the same. [2009-05-22 10:17:17] martin2007 at laposte dot net Description: urlencode and rawurlencode are not RFC-1738 compliant. RFC-1738 states: " Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL." Later on, the grammar is as follows: unreserved = alpha | digit | safe | extra safe = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | "'" | "(" | ")" | "," However, urlencode and rawurlencode encode $!*'(), Note that, except for "$" and ",", this is also true for RFC-2396 (URI). The main problem is that Google uses another encoding scheme. When you have URLs containing these characters, your weblogs contain several different URLs for the same resource. It might also confuse some web server implementations. See: http://www.monperrus.net/martin/googenc/ Reproduce code: --- echo urlencode("$!*'(),"); echo rawurlencode("$!*'(),"); Expected result: $!*'(), $!*'(), Actual result: -- %24%21%2A%27%28%29%2C %24%21%2A%27%28%29%2C -- Edit this bug report at http://bugs.php.net/?id=48360&edit=1
#48365 [Fbk]: glob() function returns empty array
ID: 48365 Updated by: j...@php.net Reported By: peter dot chen at itg dot com Status: Feedback Bug Type: Apache2 related Operating System: sparc-sol2.10 PHP Version: 5.2.9 New Comment: Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/*"));' Previous Comments: [2009-05-28 16:49:23] j...@php.net Exactly what Solaris version are you on? Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/"));' [2009-05-27 23:05:14] peter dot chen at itg dot com My apologies, I did not read all the instructions. Is there a flag I needed to enable when building php? As for the code, I mistakenly left the ';' that caused the parse error. The code should be as follows: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*')); print("***"); print("scandir:"); print_r(scandir($path)); ?> [2009-05-23 17:03:08] j...@php.net You obviously didn't follow the url provided in the email. Please, do not "Add Comment" to your own report, use the "Edit Submission" (where the link in the email points too. And now, please provide the code that actually causes the problem. That code works fine everywhere. [2009-05-23 10:35:41] carsten_sttgt at gmx dot de > print_r(glob($path . '*.*';)); This line give you a parse error. Must be: | print_r(glob($path . '*.*')); Apart from this, the code is working for me (Win,BSD). BTW: > [0] => . > [1] => .. > [2] => authtest With your code, this can't be part of the result from glob(). Regards, Carsten [2009-05-22 21:09:23] peter dot chen at itg dot com http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*';)); print("***"); print("scandir:"); print_r(scandir($path)); ?> 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/48365 -- Edit this bug report at http://bugs.php.net/?id=48365&edit=1
#48365 [Opn->Fbk]: glob() function returns empty array
ID: 48365 Updated by: j...@php.net Reported By: peter dot chen at itg dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: sparc-sol2.10 PHP Version: 5.2.9 New Comment: Exactly what Solaris version are you on? Try this on command line: # php -r 'var_dump(glob("/home/apache/htdocs/testkt/"));' Previous Comments: [2009-05-27 23:05:14] peter dot chen at itg dot com My apologies, I did not read all the instructions. Is there a flag I needed to enable when building php? As for the code, I mistakenly left the ';' that caused the parse error. The code should be as follows: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*')); print("***"); print("scandir:"); print_r(scandir($path)); ?> [2009-05-23 17:03:08] j...@php.net You obviously didn't follow the url provided in the email. Please, do not "Add Comment" to your own report, use the "Edit Submission" (where the link in the email points too. And now, please provide the code that actually causes the problem. That code works fine everywhere. [2009-05-23 10:35:41] carsten_sttgt at gmx dot de > print_r(glob($path . '*.*';)); This line give you a parse error. Must be: | print_r(glob($path . '*.*')); Apart from this, the code is working for me (Win,BSD). BTW: > [0] => . > [1] => .. > [2] => authtest With your code, this can't be part of the result from glob(). Regards, Carsten [2009-05-22 21:09:23] peter dot chen at itg dot com http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> glob test glob:"); print_r(glob($path . '*.*';)); print("***"); print("scandir:"); print_r(scandir($path)); ?> [2009-05-22 19:43:37] j...@php.net Please provide proper example script. 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/48365 -- Edit this bug report at http://bugs.php.net/?id=48365&edit=1
#48413 [Fbk]: floating-point formats on 64 bit systems
ID: 48413 Updated by: j...@php.net Reported By: vgabor at gmail dot com Status: Feedback Bug Type: Math related Operating System: Linux x86_64 PHP Version: 5.2.9 New Comment: And when you post example scripts, put tags around and also provide the expected / actual outputs. Previous Comments: [2009-05-28 16:43:12] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-28 12:41:27] vgabor at gmail dot com Description: This in not quite bug, I think everybody know well the possible float-integer conversation problems on the usual 32 bit systems, but the 64 bit systems give us some new ones. On 64 bit, the float becomes actually less precise then the integer, because the binary64 (double) floating point format what the PHP using is up to 52+1 bits while the integer 63+1 bit. Most of the mathematical functions are using and convert the numbers to float which historically give better result on 32 bit system (52+1 bit versus 31+1 bit) but with 64 bit integer thats unfortunately not the case (52+1 bit instead of 63+1 bit) Solving this problem I would recommend to introduce in the PHP the binary128 (quad) floating point format from the latest floating-point arithmetic standard (IEEE 754-2008, last year) which would give us 112+1 bits precision. Reproduce code: --- Just a quick example when it comes to numbers above 52+1 bit (the / operator convert the result to float which leads to precision loss on 64 bit systems): ini_set('precision', 99); $X=4485476582; $Y=4485476608; echo "($X/10*10) === $X: ".((int)($X/10*10) === $X ? 'true' : 'false')."\n"; echo "($X/10*10) === $Y: ".((int)($X/10*10) === $Y ? 'true' : 'false')."\n\n"; echo ($X)."\n"; echo ($X/10)."\n"; echo ($X/10*10)."\n"; -- Edit this bug report at http://bugs.php.net/?id=48413&edit=1
#48413 [Opn->Fbk]: floating-point formats on 64 bit systems
ID: 48413 Updated by: j...@php.net Reported By: vgabor at gmail dot com -Status: Open +Status: Feedback Bug Type: Math related Operating System: Linux x86_64 PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-05-28 12:41:27] vgabor at gmail dot com Description: This in not quite bug, I think everybody know well the possible float-integer conversation problems on the usual 32 bit systems, but the 64 bit systems give us some new ones. On 64 bit, the float becomes actually less precise then the integer, because the binary64 (double) floating point format what the PHP using is up to 52+1 bits while the integer 63+1 bit. Most of the mathematical functions are using and convert the numbers to float which historically give better result on 32 bit system (52+1 bit versus 31+1 bit) but with 64 bit integer thats unfortunately not the case (52+1 bit instead of 63+1 bit) Solving this problem I would recommend to introduce in the PHP the binary128 (quad) floating point format from the latest floating-point arithmetic standard (IEEE 754-2008, last year) which would give us 112+1 bits precision. Reproduce code: --- Just a quick example when it comes to numbers above 52+1 bit (the / operator convert the result to float which leads to precision loss on 64 bit systems): ini_set('precision', 99); $X=4485476582; $Y=4485476608; echo "($X/10*10) === $X: ".((int)($X/10*10) === $X ? 'true' : 'false')."\n"; echo "($X/10*10) === $Y: ".((int)($X/10*10) === $Y ? 'true' : 'false')."\n\n"; echo ($X)."\n"; echo ($X/10)."\n"; echo ($X/10*10)."\n"; -- Edit this bug report at http://bugs.php.net/?id=48413&edit=1
#43189 [Opn]: Fails to link iconv
ID: 43189 Updated by: phi...@php.net Reported By: meh at mailinator dot com Status: Open Bug Type: ICONV related Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2007-11-04 (snap) New Comment: For me, the following solution worked: http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while- compiling-php-528/ Which involves moving around $(MH_BUNDLE_FLAGS). Looks like a different yet related bug however, but Previous Comments: [2009-05-24 15:54:54] meh at mailinator dot com It still fails for me in php5.3-200905241430. This workaround still necessary: sudo mv /usr/include/iconv.h /usr/include/iconv.h.leo_orig sudo ln -s /sw/include/iconv.h /usr/include/iconv.h rm ext/iconv/*.*o make [2009-04-30 13:03:17] scott...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-04-24 17:38:06] richard dot sentino at mindginative dot com This configure option worked for me: --with-iconv=/opt/local (Mac OS 10.5.6, PHP 5.2.9, iconv installed in /opt/local using macports) but it doesn't work with this configure option : --with-iconv=shared,/opt/local the configure passed and make passed but iconv won't show up when I do php -m [2009-03-27 06:26:43] senz at senz dot su Changing --with-iconv-dir to --with-iconv=shared,/opt/local solve it on my system. /opt/local = macports with iconv [2009-03-27 06:10:22] senz at senz dot su To scott...@php.net: here's my config.log from compilation with error. iconv compiled by macports. --with-iconv-dir=shared,/opt/local and static both failed. http://rapidshare.com/files/214033749/config.log.html i also send a copy on your email. 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/43189 -- Edit this bug report at http://bugs.php.net/?id=43189&edit=1
#48415 [Opn->Bgs]: PHP doesn't read the configurations propertly
ID: 48415 Updated by: j...@php.net Reported By: nicky_l at hotmail dot fr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP Pro SP3 PHP Version: 5.2.9 New Comment: Use fastcgi with IIS. See http://php.iis.net/ for more. If you have some problems with Apache2, please submit a report that has ONLY that problem in it. Previous Comments: [2009-05-28 15:47:38] nicky_l at hotmail dot fr Description: Hi, I am encountering exactly the same problems as those mentionned below by rafael dot amador at gmail dot com exept that I am using an APACHE 2.2 server. So UP please. If anyone in the team or any experimented developer here has got any idea of how to deal with this issue, will much apperciated Thanks inn advance [26 Jun 2006 6:30pm UTC] rafael dot amador at gmail dot com Description: in IIS 5.1, PHP ISAPI Module and .Net framework 2.0 installed, following instructions from install.php, PHP doesn't read the options in file php.ini if i put php.ini in c:\php\ (the webserver init php but you can't configure any option, php don't load any modules and in phpinfo() page you look strange values) example: Configuration File (php.ini) Path: "C:\WINDOWS" must be "c:\php\php.ini" extension_dir: "C:\php5" "C:\php5" in phpinfo() in php.ini the value is: extension_dir = ""c:/php/ext/" i've PATH pointing to c:\php\, my document_root is well configured and i put php.ini in other place php shows message "No input file specified." i'm experimenting the Bug #37843 and other bug (if you put php5isapi.dll in ISAPI Filters when you shutdown the server ISS crash allways) Reproduce code: --- Expected result: that my changes to php.ini are reflected in phpinfo() Actual result: -- php shows strange parameter configurations (i can't load any module) [26 Jun 2006 6:46pm UTC] tony2...@php.net Did you add c:\php to your PATH environment variable? [26 Jun 2006 6:50pm UTC] rafael dot amador at gmail dot com yeah sure i've checked the PATH enviroment variable and c:\php is present [26 Jun 2006 6:52pm UTC] tony2...@php.net And did you reboot after that? [26 Jun 2006 6:54pm UTC] rafael dot amador at gmail dot com sure i followed all instructions [26 Jun 2006 9:09pm UTC] rafael dot amador at gmail dot com i rebooted my server and again i've the same result [27 Jun 2006 2:16am UTC] rafael dot amador at gmail dot com i configured the php file with the registry entry pointing to it and didn't work but if i comment the doc_root option in php.ini all works WELL. a couple of questions come to me now: why the windows PATH method doesn't works? why the registry method works only with doc_root disabled? i saw a lot of bugs that have similar behavior. check this beacuse if isn't a bug then isn't documentated. [27 Sep 2006 7:25am UTC] mcloudteo at hotmail dot com Do this: * Go to Control Panel and open the System icon (Start -> Settings -> Control Panel -> System, or just Start -> Control Panel -> System for Windows XP/2003) * Go to the Advanced tab * Click on the 'Environment Variables' button * Look into the 'System variables' pane * Click on 'New' and enter 'PHPRC' as the variable name and the directory where php.ini is located as the variable value (e.g. C:\php) * Press OK and restart your computer [22 Oct 2006 8:45pm UTC] rafael dot amador at gmail dot com i've perfectly told that any other method works, with this statement i mean any other method DOESN'T WORK. and by the way i'm reporting a BUG i've a work arround but the bug still remains in the code. i've solved this with the register method now i've my server working with this method but the point here is that the PATH method doesn't work ... i've spend a lot of time reporting this bug and following the progress of it. i'm waiting that anyone there (Zend-PHP developer staff) take this seriously don't give me a pretext to close this bug. This danm bug is giving headaches to more than a couple of IT admins. i'm very annoyed about the response time showing a profesionless attitude ... sorry guys but it's the truth [16 Apr 2007 8:12pm UTC] sni...@php.net It's not quite clear what does not work for you: a) Are you able to run PHP scripts at all? b) Does removing 'doc_root' setting from php.ini really fix this? c) How about running PHP as FastCGI? (I prefer this myself, running PHP as module is so 90's :) [16 Apr 2007 9:08pm UTC] rafael dot amador at gmail dot com ok the point here that using ISAPI module in IIS and trying to use the Path method to configure the module, makes that PHP doesn't recognize propertly the php.ini path and its configuration that situation makes that php doesn't load any additional modules including mysqli and any other
#48415 [NEW]: PHP doesn't read the configurations propertly
From: nicky_l at hotmail dot fr Operating system: Windows XP Pro SP3 PHP version: 5.2.9 PHP Bug Type: Apache2 related Bug description: PHP doesn't read the configurations propertly Description: Hi, I am encountering exactly the same problems as those mentionned below by rafael dot amador at gmail dot com exept that I am using an APACHE 2.2 server. So UP please. If anyone in the team or any experimented developer here has got any idea of how to deal with this issue, will much apperciated Thanks inn advance [26 Jun 2006 6:30pm UTC] rafael dot amador at gmail dot com Description: in IIS 5.1, PHP ISAPI Module and .Net framework 2.0 installed, following instructions from install.php, PHP doesn't read the options in file php.ini if i put php.ini in c:\php\ (the webserver init php but you can't configure any option, php don't load any modules and in phpinfo() page you look strange values) example: Configuration File (php.ini) Path: "C:\WINDOWS" must be "c:\php\php.ini" extension_dir: "C:\php5" "C:\php5" in phpinfo() in php.ini the value is: extension_dir = ""c:/php/ext/" i've PATH pointing to c:\php\, my document_root is well configured and i put php.ini in other place php shows message "No input file specified." i'm experimenting the Bug #37843 and other bug (if you put php5isapi.dll in ISAPI Filters when you shutdown the server ISS crash allways) Reproduce code: --- Expected result: that my changes to php.ini are reflected in phpinfo() Actual result: -- php shows strange parameter configurations (i can't load any module) [26 Jun 2006 6:46pm UTC] tony2...@php.net Did you add c:\php to your PATH environment variable? [26 Jun 2006 6:50pm UTC] rafael dot amador at gmail dot com yeah sure i've checked the PATH enviroment variable and c:\php is present [26 Jun 2006 6:52pm UTC] tony2...@php.net And did you reboot after that? [26 Jun 2006 6:54pm UTC] rafael dot amador at gmail dot com sure i followed all instructions [26 Jun 2006 9:09pm UTC] rafael dot amador at gmail dot com i rebooted my server and again i've the same result [27 Jun 2006 2:16am UTC] rafael dot amador at gmail dot com i configured the php file with the registry entry pointing to it and didn't work but if i comment the doc_root option in php.ini all works WELL. a couple of questions come to me now: why the windows PATH method doesn't works? why the registry method works only with doc_root disabled? i saw a lot of bugs that have similar behavior. check this beacuse if isn't a bug then isn't documentated. [27 Sep 2006 7:25am UTC] mcloudteo at hotmail dot com Do this: * Go to Control Panel and open the System icon (Start -> Settings -> Control Panel -> System, or just Start -> Control Panel -> System for Windows XP/2003) * Go to the Advanced tab * Click on the 'Environment Variables' button * Look into the 'System variables' pane * Click on 'New' and enter 'PHPRC' as the variable name and the directory where php.ini is located as the variable value (e.g. C:\php) * Press OK and restart your computer [22 Oct 2006 8:45pm UTC] rafael dot amador at gmail dot com i've perfectly told that any other method works, with this statement i mean any other method DOESN'T WORK. and by the way i'm reporting a BUG i've a work arround but the bug still remains in the code. i've solved this with the register method now i've my server working with this method but the point here is that the PATH method doesn't work ... i've spend a lot of time reporting this bug and following the progress of it. i'm waiting that anyone there (Zend-PHP developer staff) take this seriously don't give me a pretext to close this bug. This danm bug is giving headaches to more than a couple of IT admins. i'm very annoyed about the response time showing a profesionless attitude ... sorry guys but it's the truth [16 Apr 2007 8:12pm UTC] sni...@php.net It's not quite clear what does not work for you: a) Are you able to run PHP scripts at all? b) Does removing 'doc_root' setting from php.ini really fix this? c) How about running PHP as FastCGI? (I prefer this myself, running PHP as module is so 90's :) [16 Apr 2007 9:08pm UTC] rafael dot amador at gmail dot com ok the point here that using ISAPI module in IIS and trying to use the Path method to configure the module, makes that PHP doesn't recognize propertly the php.ini path and its configuration that situation makes that php doesn't load any additional modules including mysqli and any others... becoming any php script in a useless piece of code... stills run but is not capable to call any functions of any module... i hope that this explanation make you clear what i'm reporting here... response to the questions a) with the specified conditions, yes, but without any configuration available no additional modules, php scripts become useless
#48414 [Opn->Fbk]: The FastCGI process exited unexpectedly
ID: 48414 Updated by: paj...@php.net Reported By: dannyoneill at ntlworld dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2003 Server PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2009-05-28 13:57:01] dannyoneill at ntlworld dot com Description: On a freshly built (and existing) Windows server with PHP 5.2.9 and FastCGI the following error occurs when trying to access phpMyAdmin when register_globals is set to on; --- FastCGI Error The FastCGI Handler was unable to process the request. Error Details: * The FastCGI process exited unexpectedly * Error Number: -1073741819 (0xc005). * Error Description: Unknown Error HTTP Error 500 - Server Error. Internet Information Services (IIS) - I have built a fresh server and can re-create this each time. This only occurs when using fastcgi. Reproduce code: --- Standard install of phpMyAdmin Expected result: Sucessful logon Actual result: -- FastCGI Error The FastCGI Handler was unable to process the request. Error Details: * The FastCGI process exited unexpectedly * Error Number: -1073741819 (0xc005). * Error Description: Unknown Error HTTP Error 500 - Server Error. Internet Information Services (IIS) -- Edit this bug report at http://bugs.php.net/?id=48414&edit=1
#48378 [Ver->Csd]: exif_read_data() segfaults on certain corrupted .jpeg files
ID: 48378 Updated by: paj...@php.net Reported By: phpbug dot exif at sub dot noloop dot net -Status: Verified +Status: Closed Bug Type: EXIF related Operating System: * PHP Version: 5.*, 6CVS (2009-05-27) -Assigned To: +Assigned To: pajoye New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-05-28 12:49:36] il...@php.net On 64 bit linux I get no crash and no complaints from valgrind either. [2009-05-27 19:05:13] j...@php.net Verified with proper test script, this function never accepted array parameters: http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg";, "FILE,COMPUTED,ANY_TAG" ); Same backtrace (just a bit different line numbers) with all branches. [2009-05-26 05:24:23] scott...@php.net I can confirm here on OSX. #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 1088return (((uchar *)value)[1] << 8) | ((uchar *)value)[0]; (gdb) bt #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 #1 0x00037a01 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffef8c, dir_start=0x7100b1 , offset_base=0x3100a8 "II*", IFDlength=126, displacement=12, section_index=3) at /Users/scott/dev/php5_2/ext/exif/exif.c:3140 #2 0x00037d92 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffef8c, CharBuf=0x3100a8 "II*", length=126, displacement=12) at /Users/scott/dev/php5_2/ext/exif/exif.c:3221 #3 0x00037e92 in exif_process_APP1 (ImageInfo=0xbfffef8c, CharBuf=0x3100a0 "", length=134, displacement=4) at /Users/scott/dev/php5_2/ext/exif/exif.c:3246 #4 0x000384d2 in exif_scan_JPEG_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3385 #5 0x000393c4 in exif_scan_FILE_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3757 #6 0x0003a073 in exif_read_file (ImageInfo=0xbfffef8c, FileName=0x30d2d4 "hello-s148.jpeg", read_thumbnail=0, read_all=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:3902 [2009-05-25 20:49:59] phpbug dot exif at sub dot noloop dot net That's odd. I'm getting 100% reproducible crash on both the latest 5.2 cvs snapshot, as well as the php build included in Debian Linux 5.0.1 (stable) (which is 5.2.6+some debian patches) I'm using Linux 2.6.29.4, Debian 5.0.1, gcc version 4.3.2 (Debian 4.3.2-1.1) on an i686 (32bit) machine with 3gb ram. To compile, I did: './configure' '--prefix=/home/frode/temp/z/zinst3' '--disable-all' '--enable-exif' make cli Are you running on 64bit, or perhaps some other distro with a different version of gcc etc? [2009-05-25 19:59:23] il...@php.net I am getting the following error messages, but no crash: Warning: exif_read_data(hello-s148.jpeg): Illegal IFD size: x4B + 2 + x*12 = x4B > x007E in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Error reading from file: got=x08B4(=2228) != itemlen-2=x1FFE(=8190) in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Invalid JPEG file in exif.php on line 2 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/48378 -- Edit this bug report at http://bugs.php.net/?id=48378&edit=1
#48414 [NEW]: The FastCGI process exited unexpectedly
From: dannyoneill at ntlworld dot com Operating system: Windows 2003 Server PHP version: 5.2.9 PHP Bug Type: Reproducible crash Bug description: The FastCGI process exited unexpectedly Description: On a freshly built (and existing) Windows server with PHP 5.2.9 and FastCGI the following error occurs when trying to access phpMyAdmin when register_globals is set to on; --- FastCGI Error The FastCGI Handler was unable to process the request. Error Details: * The FastCGI process exited unexpectedly * Error Number: -1073741819 (0xc005). * Error Description: Unknown Error HTTP Error 500 - Server Error. Internet Information Services (IIS) - I have built a fresh server and can re-create this each time. This only occurs when using fastcgi. Reproduce code: --- Standard install of phpMyAdmin Expected result: Sucessful logon Actual result: -- FastCGI Error The FastCGI Handler was unable to process the request. Error Details: * The FastCGI process exited unexpectedly * Error Number: -1073741819 (0xc005). * Error Description: Unknown Error HTTP Error 500 - Server Error. Internet Information Services (IIS) -- Edit bug report at http://bugs.php.net/?id=48414&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48414&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48414&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48414&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48414&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48414&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48414&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48414&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48414&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48414&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48414&r=support Expected behavior: http://bugs.php.net/fix.php?id=48414&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48414&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48414&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48414&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48414&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48414&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48414&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48414&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48414&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48414&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48414&r=mysqlcfg
#48378 [Ver]: exif_read_data() segfaults on certain corrupted .jpeg files
ID: 48378 Updated by: il...@php.net Reported By: phpbug dot exif at sub dot noloop dot net Status: Verified Bug Type: EXIF related Operating System: * PHP Version: 5.*, 6CVS (2009-05-27) New Comment: On 64 bit linux I get no crash and no complaints from valgrind either. Previous Comments: [2009-05-27 19:05:13] j...@php.net Verified with proper test script, this function never accepted array parameters: http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg";, "FILE,COMPUTED,ANY_TAG" ); Same backtrace (just a bit different line numbers) with all branches. [2009-05-26 05:24:23] scott...@php.net I can confirm here on OSX. #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 1088return (((uchar *)value)[1] << 8) | ((uchar *)value)[0]; (gdb) bt #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 #1 0x00037a01 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffef8c, dir_start=0x7100b1 , offset_base=0x3100a8 "II*", IFDlength=126, displacement=12, section_index=3) at /Users/scott/dev/php5_2/ext/exif/exif.c:3140 #2 0x00037d92 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffef8c, CharBuf=0x3100a8 "II*", length=126, displacement=12) at /Users/scott/dev/php5_2/ext/exif/exif.c:3221 #3 0x00037e92 in exif_process_APP1 (ImageInfo=0xbfffef8c, CharBuf=0x3100a0 "", length=134, displacement=4) at /Users/scott/dev/php5_2/ext/exif/exif.c:3246 #4 0x000384d2 in exif_scan_JPEG_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3385 #5 0x000393c4 in exif_scan_FILE_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3757 #6 0x0003a073 in exif_read_file (ImageInfo=0xbfffef8c, FileName=0x30d2d4 "hello-s148.jpeg", read_thumbnail=0, read_all=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:3902 [2009-05-25 20:49:59] phpbug dot exif at sub dot noloop dot net That's odd. I'm getting 100% reproducible crash on both the latest 5.2 cvs snapshot, as well as the php build included in Debian Linux 5.0.1 (stable) (which is 5.2.6+some debian patches) I'm using Linux 2.6.29.4, Debian 5.0.1, gcc version 4.3.2 (Debian 4.3.2-1.1) on an i686 (32bit) machine with 3gb ram. To compile, I did: './configure' '--prefix=/home/frode/temp/z/zinst3' '--disable-all' '--enable-exif' make cli Are you running on 64bit, or perhaps some other distro with a different version of gcc etc? [2009-05-25 19:59:23] il...@php.net I am getting the following error messages, but no crash: Warning: exif_read_data(hello-s148.jpeg): Illegal IFD size: x4B + 2 + x*12 = x4B > x007E in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Error reading from file: got=x08B4(=2228) != itemlen-2=x1FFE(=8190) in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Invalid JPEG file in exif.php on line 2 [2009-05-24 20:58:14] phpbug dot exif at sub dot noloop dot net Description: There seems to be a problem in exif_read_data(), where some fields representing offsets(?) are taken directly from the file without being validated, resulting in a segmentation fault. I originally found this issue by fooling around with the "zzuf" fuzzer, and reported a very similar bug in the "jhead" exif utility at http://bugs.debian.org/530401 Original image can be found at: http://www.noloop.net/bugs/php/001-exif/hello.jpeg Corrupted image can be found at: http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg Reproduce code: --- , offset_base=0x8ef76b8 "II*", IFDlength=15055, displacement=30, section_index=3) at /home/frode/temp/z/z3/php5.2-200905241830/ext/exif/exif.c:1088 1088return (((uchar *)value)[1] << 8) | ((uchar *)value)[0]; (gdb) up #1 0x0808e6ca in exif_read_file (ImageInfo=0xbfc893b8, FileName=, read_thumbnail=, read_all=0) at /home/frode/temp/z/z3/php5.2-200905241830/ext/exif/exif.c:3221 3221exif_process_IFD_in_JPEG(ImageInfo, CharBuf+offset_of_ifd, CharBuf, length/*-14*/, displacement, SECTION_IFD0 TSRMLS_CC); Note the "dir_start" address being out of bounds, which causes the "((uchar *)value)[1]" to segfault. (The function names are a bit confusing, maybe it's because of method inlining?) -- Edit this bug report at http://bugs.php.net/?id=48378&edit=1
#48413 [NEW]: floating-point formats on 64 bit systems
From: vgabor at gmail dot com Operating system: Linux x86_64 PHP version: 5.2.9 PHP Bug Type: Math related Bug description: floating-point formats on 64 bit systems Description: This in not quite bug, I think everybody know well the possible float-integer conversation problems on the usual 32 bit systems, but the 64 bit systems give us some new ones. On 64 bit, the float becomes actually less precise then the integer, because the binary64 (double) floating point format what the PHP using is up to 52+1 bits while the integer 63+1 bit. Most of the mathematical functions are using and convert the numbers to float which historically give better result on 32 bit system (52+1 bit versus 31+1 bit) but with 64 bit integer thats unfortunately not the case (52+1 bit instead of 63+1 bit) Solving this problem I would recommend to introduce in the PHP the binary128 (quad) floating point format from the latest floating-point arithmetic standard (IEEE 754-2008, last year) which would give us 112+1 bits precision. Reproduce code: --- Just a quick example when it comes to numbers above 52+1 bit (the / operator convert the result to float which leads to precision loss on 64 bit systems): ini_set('precision', 99); $X=4485476582; $Y=4485476608; echo "($X/10*10) === $X: ".((int)($X/10*10) === $X ? 'true' : 'false')."\n"; echo "($X/10*10) === $Y: ".((int)($X/10*10) === $Y ? 'true' : 'false')."\n\n"; echo ($X)."\n"; echo ($X/10)."\n"; echo ($X/10*10)."\n"; -- Edit bug report at http://bugs.php.net/?id=48413&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48413&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48413&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48413&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48413&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48413&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48413&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48413&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48413&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48413&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48413&r=support Expected behavior: http://bugs.php.net/fix.php?id=48413&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48413&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48413&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48413&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48413&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48413&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48413&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48413&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48413&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48413&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48413&r=mysqlcfg
#48412 [Opn->Fbk]: session_start error send internal server error 500
ID: 48412 Updated by: paj...@php.net Reported By: plasmapermanent at msn dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows XP SP3 PHP Version: 5.2.9 New Comment: 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. Previous Comments: [2009-05-28 12:31:33] plasmapermanent at msn dot com Description: Just insert session_start() into code and got error. I try to insert top of code. It still error. Reproduce code: --- Source Code http://www.thaicybergames.com/webboard/index.php?topic=108158.0 MySQL CREATE TABLE IF NOT EXISTS `p28officer` ( `id` double unsigned NOT NULL, `user` char(20) COLLATE utf8_bin NOT NULL, `pass` char(20) COLLATE utf8_bin NOT NULL, `ldate` date DEFAULT NULL, `ltime` time DEFAULT NULL, `ip` varchar(15) COLLATE utf8_bin DEFAULT NULL, `lv` tinyint(4) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin; INSERT INTO `p28officer` (`id`, `user`, `pass`, `ldate`, `ltime`, `ip`, `lv`) VALUES (, 'xxx', 'xxx', '2009-05-28', '20:02:00', '127.0.0.1', 9); Expected result: I just send variable name and pass into this page. It would be can use session and remember "ssid" variable as session to use in other pages. Actual result: -- This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying. If I remove that line. It work fine. But can't use session. Juse enable that line this error was come. -- Edit this bug report at http://bugs.php.net/?id=48412&edit=1
#48412 [NEW]: session_start error send internal server error 500
From: plasmapermanent at msn dot com Operating system: Windows XP SP3 PHP version: 5.2.9 PHP Bug Type: Session related Bug description: session_start error send internal server error 500 Description: Just insert session_start() into code and got error. I try to insert top of code. It still error. Reproduce code: --- Source Code http://www.thaicybergames.com/webboard/index.php?topic=108158.0 MySQL CREATE TABLE IF NOT EXISTS `p28officer` ( `id` double unsigned NOT NULL, `user` char(20) COLLATE utf8_bin NOT NULL, `pass` char(20) COLLATE utf8_bin NOT NULL, `ldate` date DEFAULT NULL, `ltime` time DEFAULT NULL, `ip` varchar(15) COLLATE utf8_bin DEFAULT NULL, `lv` tinyint(4) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin; INSERT INTO `p28officer` (`id`, `user`, `pass`, `ldate`, `ltime`, `ip`, `lv`) VALUES (, 'xxx', 'xxx', '2009-05-28', '20:02:00', '127.0.0.1', 9); Expected result: I just send variable name and pass into this page. It would be can use session and remember "ssid" variable as session to use in other pages. Actual result: -- This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying. If I remove that line. It work fine. But can't use session. Juse enable that line this error was come. -- Edit bug report at http://bugs.php.net/?id=48412&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48412&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48412&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48412&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48412&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48412&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48412&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48412&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48412&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48412&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48412&r=support Expected behavior: http://bugs.php.net/fix.php?id=48412&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48412&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48412&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48412&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48412&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48412&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48412&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48412&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48412&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48412&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48412&r=mysqlcfg
#48276 [Asn]: date('Y') returns 0000
ID: 48276 Updated by: der...@php.net Reported By: info at programmiernutte dot net Status: Assigned Bug Type: Date/time related Operating System: Mac OS X 10.4 PPC PHP Version: 5.3.0RC2 Assigned To: derick New Comment: Seems like it's an issue in slprintf: 1017switch (format[i]) { (gdb) 1043timelib_sll year = PHP_LLABS(t->y); (gdb) print year $1 = 1230768000 (gdb) next 1044length = slprintf(buffer, 32, "%s%04ld", t->y < 0 ? "-" : "", year); break; (gdb) print year $2 = 2009 (gdb) next 1124smart_str_appendl(&string, buffer, length); (gdb) print buffer $3 = "\000\000\004\202\000\000\000\000\000\000\000\000I\\\a\200\000\000\000\000\000\000\0006\000\000\000\000" (gdb) next 1015for (i = 0; i < format_len; i++) { (gdb) print &string $4 = (smart_str *) 0xffa1cde0 (gdb) print string $5 = {c = 0x1071f060 "\020q�X\020c\003�", len = 4, a = 78} Previous Comments: [2009-05-28 08:42:28] der...@php.net Oh, I had forgotten about that PPC machine. I'll have a look. [2009-05-28 03:56:41] scott...@php.net We have a PPC test machine, Derick has access and I can set up other accounts if needed. [2009-05-28 00:45:05] ras...@php.net So there is an endian issue somewhere. How are you with gdb? Could you set a breakpoint on the function and work your way through it and figure out where it goes south? [2009-05-28 00:40:27] info at programmiernutte dot net I just verified the issue unter Linux PPC, Debian Lenny PPC to be specific. [2009-05-27 23:07:35] info at programmiernutte dot net PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same results. 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/48276 -- Edit this bug report at http://bugs.php.net/?id=48276&edit=1
#48276 [Opn->Asn]: date('Y') returns 0000
ID: 48276 Updated by: der...@php.net Reported By: info at programmiernutte dot net -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Mac OS X 10.4 PPC PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: derick New Comment: Oh, I had forgotten about that PPC machine. I'll have a look. Previous Comments: [2009-05-28 03:56:41] scott...@php.net We have a PPC test machine, Derick has access and I can set up other accounts if needed. [2009-05-28 00:45:05] ras...@php.net So there is an endian issue somewhere. How are you with gdb? Could you set a breakpoint on the function and work your way through it and figure out where it goes south? [2009-05-28 00:40:27] info at programmiernutte dot net I just verified the issue unter Linux PPC, Debian Lenny PPC to be specific. [2009-05-27 23:07:35] info at programmiernutte dot net PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same results. [2009-05-27 22:00:56] j at teamonetickets dot com I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2. $oDateTime = new DateTime(); print_r($oDateTime); Result: DateTime Object ( [date] => 2009-05-27 14:57:33 [timezone_type] => 3 [timezone] => America/Phoenix ) echo date('y'); Result: 09 echo date('Y'); Result: 2009 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/48276 -- Edit this bug report at http://bugs.php.net/?id=48276&edit=1