#33720 [NEW]: mb_encode_mimeheader does not work
From: s dot masugata at digicom dot dnp dot co dot jp Operating system: Solaris8 PHP version: 4.4.0 PHP Bug Type: mbstring related Bug description: mb_encode_mimeheader does not work Description: http://bugs.php.net/bug.php?id=32311 mb_encode_mimeheader is did not operate by the influence that corrected this problem. Reproduce code: --- Expected result: string(34) "=?ISO-2022-JP?B?GyRCST1CahsoQg==?=" Actual result: -- string(2) "hL" -- Edit bug report at http://bugs.php.net/?id=33720&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33720&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33720&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33720&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33720&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33720&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33720&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33720&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33720&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33720&r=support Expected behavior: http://bugs.php.net/fix.php?id=33720&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33720&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33720&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33720&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33720&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33720&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33720&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33720&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33720&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33720&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33720&r=mysqlcfg
#33719 [NEW]: foreach clash
From: s dot masugata at digicom dot dnp dot co dot jp Operating system: Solaris8 PHP version: 4.4.0 PHP Bug Type: *General Issues Bug description: foreach clash Description: KEY and VALUE of foreach are made the duplicate variable, strange operation is done. Reproduce code: --- $val ) { // echo "debug {$val}\n"; // this comment is removed, stranger operation is done. } print_r( $arr ); ?> Expected result: Array ( [0] => 1 [1] => 123 [2] => 12345 ) Actual result: -- Array ( [0] => 1 [1] => 2 [2] => ) /usr/local/src/php-4.4.0/Zend/zend_execute.c(2436) : Freeing 0x0838B164 (12 bytes), script=f.php -- Edit bug report at http://bugs.php.net/?id=33719&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33719&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33719&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33719&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33719&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33719&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33719&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33719&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33719&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33719&r=support Expected behavior: http://bugs.php.net/fix.php?id=33719&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33719&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33719&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33719&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33719&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33719&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33719&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33719&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33719&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33719&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33719&r=mysqlcfg
#33718 [NEW]: Problems with Java & PHP integration
From: tuta at digi dot com dot br Operating system: Windows 2000 PHP version: 5.0.4 PHP Bug Type: Java related Bug description: Problems with Java & PHP integration Description: Hi All, I just downloaded(few hours ago) PHP 5.04 for Windows (php-5.0.4-Win32.zip) + PECL(pecl-5.0.4-Win32.zip), and i was trying to make PHP and talk with some of my Java Classes. I created some simple files just to start, something like this: PHP Filename : "java.php" hello("All"); ?> Java: Filename: "Hello.java" class Hello { public String hello(String name) { return "Hello " + name + ", how are you?"; } } Here is my php.ini [java] java.class.path= "c:\php\ext\php_java.jar;c:\php\ext;c:\java_classes" java.home= C:\jdk1.5.0\jre\bin\ java.library.path= c:\php\ext java.library= C:\jdk1.5.0\jre\bin\server\jvm.dll When i tried to run my "java.php" on my Apache Server(2.0.53 Win32), my web browser(FireFox) showed me the message "The Document Contains no Data", and i found many messages "Parent: child process exited with status 3221225477 -- Restarting." on my Apache's log file. I also tried to run "java.php" from console(using "php.exe java.php") , but without any success and without any error message, the php.exe just jump to another line without complains. So, i tried to spy the process using some debug tools to figure it out what was the problem, and i found it inside "php_java.jar" file and here it is: - There is a little space after the name "php_java" in the file "reflect.properties"(line library=php_java), and when the "reflect.class" tries to find the lib.( System.loadLibrary(bundle.getString("library") <-- reflect.java ); it will always look for "php_java .dll"(with space!). I fixed manually my "reflect.properties" and everything is fine now. I hope this information could help someone with the same problem. Best Regards, Tuta Muniz -- Edit bug report at http://bugs.php.net/?id=33718&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33718&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33718&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33718&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33718&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33718&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33718&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33718&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33718&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33718&r=support Expected behavior: http://bugs.php.net/fix.php?id=33718&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33718&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33718&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33718&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33718&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33718&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33718&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33718&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33718&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33718&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33718&r=mysqlcfg
#33717 [Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717 Updated by: [EMAIL PROTECTED] Reported By: fhenninot at freesurf dot fr Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b3 Assigned To: wez New Comment: Doh. Like this: $stmt = $db->prepare("SELECT * from database where location like ?"); $stmt->execute(array(":memory:")); Previous Comments: [2005-07-15 23:32:41] [EMAIL PROTECTED] BTW, if you want a workaround, you can use parameters like this: $stmt = $db->prepare("SELECT * from database where location like ?"); $stmt->execute(array(":memory")); [2005-07-15 23:30:54] [EMAIL PROTECTED] Sounds like a pretty nasty problem to me. [2005-07-15 23:01:05] fhenninot at freesurf dot fr Description: This is a bug, i think, in PHP-5.1B3 When i search a string named ':memory:' into a database field, this crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice] child pid 11338 exit signal Segmentation fault (11) I can test it on linux only! and with some apache version. Reproduce code: --- query("SELECT * FROM database WHERE location like ':memory:'"); -- Edit this bug report at http://bugs.php.net/?id=33717&edit=1
#33717 [Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717 Updated by: [EMAIL PROTECTED] Reported By: fhenninot at freesurf dot fr Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b3 Assigned To: wez New Comment: BTW, if you want a workaround, you can use parameters like this: $stmt = $db->prepare("SELECT * from database where location like ?"); $stmt->execute(array(":memory")); Previous Comments: [2005-07-15 23:30:54] [EMAIL PROTECTED] Sounds like a pretty nasty problem to me. [2005-07-15 23:01:05] fhenninot at freesurf dot fr Description: This is a bug, i think, in PHP-5.1B3 When i search a string named ':memory:' into a database field, this crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice] child pid 11338 exit signal Segmentation fault (11) I can test it on linux only! and with some apache version. Reproduce code: --- query("SELECT * FROM database WHERE location like ':memory:'"); -- Edit this bug report at http://bugs.php.net/?id=33717&edit=1
#33717 [Opn->Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717 Updated by: [EMAIL PROTECTED] Reported By: fhenninot at freesurf dot fr -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Linux -PHP Version: 5.1.0b2 +PHP Version: 5.1.0b3 -Assigned To: +Assigned To: wez New Comment: Sounds like a pretty nasty problem to me. Previous Comments: [2005-07-15 23:01:05] fhenninot at freesurf dot fr Description: This is a bug, i think, in PHP-5.1B3 When i search a string named ':memory:' into a database field, this crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice] child pid 11338 exit signal Segmentation fault (11) I can test it on linux only! and with some apache version. Reproduce code: --- query("SELECT * FROM database WHERE location like ':memory:'"); -- Edit this bug report at http://bugs.php.net/?id=33717&edit=1
#33717 [NEW]: crash 'apache' when a query contain ':memory:'
From: fhenninot at freesurf dot fr Operating system: Linux PHP version: 5.1.0b2 PHP Bug Type: PDO related Bug description: crash 'apache' when a query contain ':memory:' Description: This is a bug, i think, in PHP-5.1B3 When i search a string named ':memory:' into a database field, this crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice] child pid 11338 exit signal Segmentation fault (11) I can test it on linux only! and with some apache version. Reproduce code: --- query("SELECT * FROM database WHERE location like ':memory:'"); -- Edit bug report at http://bugs.php.net/?id=33717&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33717&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33717&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33717&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33717&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33717&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33717&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33717&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33717&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33717&r=support Expected behavior: http://bugs.php.net/fix.php?id=33717&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33717&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33717&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33717&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33717&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33717&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33717&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33717&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33717&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33717&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33717&r=mysqlcfg
#33716 [NEW]: HTTP authentication
From: jacka at torreycommerce dot com Operating system: linux PHP version: 5.0.4 PHP Bug Type: SOAP related Bug description: HTTP authentication Description: It appears that the constructor of SoapClient is completely ignoring the second argument (options). I am trying to use basic http authentication, but regardless of what I send as the options parameter I get the same result. Reproduce code: --- $woptions['soap_version']=SOAP_1_2; $woptions['login']=""; $woptions['password']=""; $client = new SoapClient("http://wsdl_that_uses_basic_HTTP_auth",$woptions); Expected result: It should return no errors or warnings. Actual result: -- PHP Warning: SoapClient::__construct(http://wsdl_that_uses_basic_HTTP_auth): failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8 PHP Warning: I/O warning : failed to load HTTP resource in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8 PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://merchant-api-qa.amazon.com/gateway/merchant-interface-mime' in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8 PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://wsdl_that_uses_basic_HTTP_auth' in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php:8 Stack trace: #0 /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php(8): SoapClient->__construct('http://wsdl_that_uses_basic_HTTP_auth', Array) #1 {main} thrown in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8 -- Edit bug report at http://bugs.php.net/?id=33716&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33716&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33716&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33716&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33716&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33716&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33716&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33716&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33716&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33716&r=support Expected behavior: http://bugs.php.net/fix.php?id=33716&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33716&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33716&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33716&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33716&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33716&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33716&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33716&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33716&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33716&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33716&r=mysqlcfg
#33713 [Opn->Bgs]: Foreach uses the same internal pointer in different iterations of recursive fns
ID: 33713 Updated by: [EMAIL PROTECTED] Reported By: bmorel at ssi dot fr -Status: Open +Status: Bogus Bug Type: Scripting Engine problem -Operating System: Fedora Core 4 +Operating System: * -PHP Version: 5.0.4 +PHP Version: 5.* New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use ArrayObject/ArrayIterator instead or as a wrapper around your arrays. Previous Comments: [2005-07-15 18:41:52] bmorel at ssi dot fr Description: Sorry if this is not a bug, but I think the behavior is not normal, even after searching the net and this bug database. It seems that, used inside a recursive function, foreach doesn't use different array pointers for each iteration of the function, but uses the same at each time. This common pointer is reseted at each foreach() call. Reproduce code: --- function recurse($doRecurse = true) { static $array = array(1,2); foreach ($array as $value) { echo $value . PHP_EOL; if ($doRecurse) recurse(false); } } recurse(); Expected result: 1 1 2 2 1 2 Actual result: -- 1 1 2 -- Edit this bug report at http://bugs.php.net/?id=33713&edit=1
#33711 [Opn->Bgs]: unset() doesn't destroy object with internal references
ID: 33711 Updated by: [EMAIL PROTECTED] Reported By: mike dot hall at twistdigital dot co dot uk -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: FreeBSD PHP Version: 5.1.0b2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2005-07-15 16:50:41] mike dot hall at twistdigital dot co dot uk Description: PHP doesn't unset an object if it contains variables that include references to itself. Despite being unset, the objects remain in memory until the end of the request. This can lead to scripts consuming large amounts of memory when larger and more complex objects are being employed. Reproduce code: --- http://www.indelible.org.uk/reproduce.php Expected result: 0 Create A Create B Destroying B Destroying A 1 Create A Create B Destroying B Destroying A 2 Create A Create B Destroying B Destroying A End of Loop Actual result: -- 0 Create A Create B 1 Create A Create B 2 Create A Create B End of Loop Destroying A Destroying B Destroying A Destroying B Destroying A Destroying B -- Edit this bug report at http://bugs.php.net/?id=33711&edit=1
#33715 [NEW]: cant use php4 with memory-limit
From: excedor at gmail dot com Operating system: linux PHP version: 4.4.0 PHP Bug Type: *Configuration Issues Bug description: cant use php4 with memory-limit Description: When I try to run php4.4.0 with this configuration: ./configure --with-apxs2=/usr/local/httpd/bin/apxs --with-mysql --prefix=/usr/local/php4 --with-libxml-dir=/usr/lib --with-zlib --with-mysql=/usr/local/mysql --enable-soap --enable-sockets --with-gettext --enable-mbstring --with-gd --with-jpeg-dir=/usr/lib --enable-memory-limit i get at SOME websites following message: Bad Gateway The proxy server received an invalid response from an upstream server. Most of the sites are working - just one drupal version does not appear (i have the same drupalversion in different directories and the other are working, but they are not as complex and filled with content like the notworking version) I didn't find the problem. I know how to compile and to get it run, so that's not the problem. When I run the same configuration without the enable-memory-limit parameter everything works perfectly (but i need memory_get_usage for some reasons, and it's only available with that parameter) is it a bug or what could be the reason? With php5 it's working but i would have to modify a LOT of things, so i would really prefer to use php4. Reproduce code: --- ./configure --with-apxs2=/usr/local/httpd/bin/apxs --with-mysql --prefix=/usr/local/php4 --with-libxml-dir=/usr/lib --with-zlib --with-mysql=/usr/local/mysql --enable-soap --enable-sockets --with-gettext --enable-mbstring --with-gd --with-jpeg-dir=/usr/lib --enable-memory-limit Expected result: The website... http://www.humano2.org Actual result: -- Bad Gateway The proxy server received an invalid response from an upstream server. -- Edit bug report at http://bugs.php.net/?id=33715&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33715&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33715&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33715&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33715&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33715&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33715&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33715&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33715&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33715&r=support Expected behavior: http://bugs.php.net/fix.php?id=33715&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33715&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33715&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33715&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33715&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33715&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33715&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33715&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33715&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33715&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33715&r=mysqlcfg
#33714 [Opn->Fbk]: Segmentation fault on interactive mode
ID: 33714 Updated by: [EMAIL PROTECTED] Reported By: dev at null dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat 9 PHP Version: 5.0.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2005-07-15 18:48:41] dev at null dot com Description: php -a http://bugs.php.net/?id=33714&edit=1
#33714 [NEW]: Segmentation fault on interactive mode
From: dev at null dot com Operating system: Redhat 9 PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: Segmentation fault on interactive mode Description: php -a http://bugs.php.net/?id=33714&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33714&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33714&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33714&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33714&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33714&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33714&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33714&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33714&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33714&r=support Expected behavior: http://bugs.php.net/fix.php?id=33714&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33714&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33714&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33714&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33714&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33714&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33714&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33714&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33714&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33714&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33714&r=mysqlcfg
#33713 [NEW]: Foreach uses the same internal pointer in different iterations of recursive fns
From: bmorel at ssi dot fr Operating system: Fedora Core 4 PHP version: 5.0.4 PHP Bug Type: Scripting Engine problem Bug description: Foreach uses the same internal pointer in different iterations of recursive fns Description: Sorry if this is not a bug, but I think the behavior is not normal, even after searching the net and this bug database. It seems that, used inside a recursive function, foreach doesn't use different array pointers for each iteration of the function, but uses the same at each time. This common pointer is reseted at each foreach() call. Reproduce code: --- function recurse($doRecurse = true) { static $array = array(1,2); foreach ($array as $value) { echo $value . PHP_EOL; if ($doRecurse) recurse(false); } } recurse(); Expected result: 1 1 2 2 1 2 Actual result: -- 1 1 2 -- Edit bug report at http://bugs.php.net/?id=33713&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33713&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33713&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33713&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33713&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33713&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33713&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33713&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33713&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33713&r=support Expected behavior: http://bugs.php.net/fix.php?id=33713&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33713&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33713&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33713&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33713&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33713&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33713&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33713&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33713&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33713&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33713&r=mysqlcfg
#33712 [NEW]: Unable to connect to Oracle database(ORA-12705)
From: lionel dot roux at bio-rad dot com Operating system: AIX5.2 PHP version: 4.4.0 PHP Bug Type: OCI8 related Bug description: Unable to connect to Oracle database(ORA-12705) Description: hello, I have the following messages using : $id=OCILogon("dtpfra","dtpfra",$db,$NLS_LANG); Warning: ocilogon(): OCISessionBegin: Error while trying to retrieve text for error ORA-12705 in /usr/local/apache2/htdocs/fonctions.php on line 27 testconn=-1 The following parameters have been set in envars: export ORA_NLS32=/home/oracle/9.2.0/ocommon/nls/admin/data export LIBPATH="/home/oracle/9.2.0/lib32:/usr/local/apache2/lib:$LIBPATH" export LD_LIBRARY_PATH="/home/oracle/9.2.0/lib:/home/oracle/9.2.0/lib32" export ORACLE_BASE="/home/oracle" export ORACLE_HOME="$ORACLE_HOME:/home/oracle/9.2.0" export TNS_ADMIN="$ORACLE_HOME/network/admin:$TNS_ADMIN" export NLS_LANG=american_america.WE8ISO8859P1 export LANG=C #export LANG=en_US export TWO_TASK=$ORACLE_HOME Reproduce code: --- putenv("ORACLE_SID=DLPFRA"); getenv("ORACLE_HOME"); getenv("TNS_ADMIN"); getenv("LD_LIBRARY_PATH"); $ORACLE_SID = getenv("ORACLE_SID"); $ORACLE_HOME = getenv("ORACLE_HOME"); $LD_LIBRARY_PATH=getenv("LD_LIBRARY_PATH"); $TNS_ADMIN=getenv("TNS_ADMIN"); $NLS_LANG=getenv("NLS_LANG"); $LANG=getenv("LANG"); print "VERIF :$ORACLE_SID, $ORACLE_HOME, $LD_LIBRARY_PATH, $TNS_ADMIN, $NLS_LANG"; $db="(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP) (HOST=FRUX33)(PORT=1521) ) ) (CONNECT_DATA=(SERVICE_NAME=dtpfra)) )"; $id=OCILogon("dtpfra","dtpfra",$db,$NLS_LANG); Expected result: Connection to the database Actual result: -- VERIF :DLPFRA, :/home/oracle/9.2.0, /home/oracle/9.2.0/lib:/home/oracle/9.2.0/lib32, :/home/oracle/9.2.0/network/admin:, american_america.WE8ISO8859P1 Warning: ocilogon(): OCISessionBegin: Error while trying to retrieve text for error ORA-12705 in /usr/local/apache2/htdocs/fonctions.php on line 27 -- Edit bug report at http://bugs.php.net/?id=33712&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33712&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33712&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33712&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33712&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33712&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33712&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33712&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33712&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33712&r=support Expected behavior: http://bugs.php.net/fix.php?id=33712&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33712&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33712&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33712&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33712&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33712&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33712&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33712&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33712&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33712&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33712&r=mysqlcfg
#33711 [NEW]: unset() doesn't destroy object with internal references
From: mike dot hall at twistdigital dot co dot uk Operating system: FreeBSD PHP version: 5.1.0b2 PHP Bug Type: Class/Object related Bug description: unset() doesn't destroy object with internal references Description: PHP doesn't unset an object if it contains variables that include references to itself. Despite being unset, the objects remain in memory until the end of the request. This can lead to scripts consuming large amounts of memory when larger and more complex objects are being employed. Reproduce code: --- http://www.indelible.org.uk/reproduce.php Expected result: 0 Create A Create B Destroying B Destroying A 1 Create A Create B Destroying B Destroying A 2 Create A Create B Destroying B Destroying A End of Loop Actual result: -- 0 Create A Create B 1 Create A Create B 2 Create A Create B End of Loop Destroying A Destroying B Destroying A Destroying B Destroying A Destroying B -- Edit bug report at http://bugs.php.net/?id=33711&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33711&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33711&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33711&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33711&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33711&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33711&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33711&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33711&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33711&r=support Expected behavior: http://bugs.php.net/fix.php?id=33711&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33711&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33711&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33711&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33711&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33711&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33711&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33711&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33711&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33711&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33711&r=mysqlcfg
#33671 [Opn->Asn]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 Updated by: [EMAIL PROTECTED] Reported By: golf at dds dot nl -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 -Assigned To: +Assigned To: derick Previous Comments: [2005-07-15 15:11:36] golf at dds dot nl I don't think this is the same bug as #32820. There seems to be a difference in that one doesn't get A GMT timestamp but one with an offset of +1 if one passes an offset to date_sunrise and date_sunset. This means that one seems to get a timestamp, but this isn't a timestamp. And with the other bugreport there seems to be a logic error, not a timestamp error. As before, when I use both functions I aspect to get a timestamp back for witch the timezone is GMT* and not in the timezone for witch I added the offset to the functions... *As is normal with a timestamp [2005-07-13 07:45:56] [EMAIL PROTECTED] Duplicate of: #32820 [2005-07-13 02:35:59] golf at dds dot nl I have also swaped lat and long and this solves my basic problem that the hours where wrong, but one can say that the bug is still there since my first suspision is correct, GMT offset is not used to calculate anything, it changes the timestamp to something that looks and feels like a timestamp but isn't since it isn't a GMT date/time combo but the GMT date/time combo + the offset. Since this isn't standard for timestamp I changed the status of this Bug to open... The algorithm looks to work acourding to this: http://williams.best.vwh.net/sunrise_sunset_algorithm.htm Where one can read the last line to see it is just added... My objection to the way the functions work probably won't make a change list, but it is something to add as a note to the manual becouse it is confusing (At least to me and perhaps more people). [2005-07-13 01:08:22] golf at dds dot nl After re-reading the source in the bug-report I now see that I passed $long and $lat where I should have passed $longitude, $latitude. I changed the code and now every thing seems oke... Sorry for the hassle made by this report but I realy missed this typo. Regards, Golf P.S. I tryd to add a comment to this bugreport (twice) but it didn't show up, so if there are more than one... [2005-07-13 00:53:07] golf at dds dot nl Description: With my current version of PHP5 (5.0.4-0.6.sarge.1 (Debian GNU/Linux) I run into an error if I use date_sunrise and date_sunset. This happens when I pass an GMT offset and results in a timestamp that has an offset of +1 hour to the actual sun set/rise on that date. Since timestamps are GMT/UTC and not bound to an timezone other that GMT/UTC this is wrong. I say this since I believe the GMT offset one can pass to the before mentioned functions is used in the calculation and the functions should return a timestamp like any other so it can be used by date and gmdate as those functions require a GMT/UTC timestamp... B.t.w. I use the max difference for some further calculations in my script, so there for the lage difference between astro and official sunset's/rises... Reproduce code: --- $latitude = 28 + (1/60*17) + (1/60/60*54); $longitude = (-(16 + (1/60*30) + (1/60/60*34))); $astro = 108; $official = (90 + (1/60*50)); echo "Local Tenerife time\n"; echo "sunriseAstro = " . gmdate("M d Y H:i:s", date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . "\n"; echo "sunriseOffical = " . gmdate("M d Y H:i:s", date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official , 1) + 60*60) . "\n"; echo "sunsetOffical = " . gmdate("M d Y H:i:s", date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official, 1) + 60*60) . "\n"; echo "sunsetAstro = " . gmdate("M d Y H:i:s", date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . "\n"; Expected result: Local Tenerife time sunriseAstro = Jul 12 2005 05:47:50 sunriseOffical = Jul 12 2005 07:02:02 sunsetOffical = Jul 12 2005 19:09:17 sunsetAstro = Jul 12 2005 20:23:27 Actual result: -- Local Tenerife time sunriseAstro = Jul 12 2005 06:47:50 sunriseOffical = Jul 12 2005 08:02:02 sunsetOffical = Jul 12 2005 20:09:17 sunsetAstro = Jul 12 2005 21:23:27 -- Edit this bug report at http://bugs.php.net/?id=33671&edit=1
#33710 [NEW]: ArrayAccess objects doen't initialize $this
From: pornel at despammed dot com Operating system: all PHP version: 5.1.0b2 PHP Bug Type: Class/Object related Bug description: ArrayAccess objects doen't initialize $this Description: In object that implements ArrayAccess and accesses itself as array inside its own method, $this is not available ("Undefined variable: this") Reproduce code: --- succeed(); $bar->fail(); Expected result: No error. Both methods should work. Actual result: -- Notice: Undefined variable: this in c:\www\test.php5 on line 13 -- Edit bug report at http://bugs.php.net/?id=33710&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33710&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33710&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33710&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33710&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33710&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33710&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33710&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33710&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33710&r=support Expected behavior: http://bugs.php.net/fix.php?id=33710&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33710&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33710&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33710&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33710&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33710&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33710&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33710&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33710&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33710&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33710&r=mysqlcfg
#33671 [Bgs->Opn]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 User updated by: golf at dds dot nl Reported By: golf at dds dot nl -Status: Bogus +Status: Open Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 New Comment: I don't think this is the same bug as #32820. There seems to be a difference in that one doesn't get A GMT timestamp but one with an offset of +1 if one passes an offset to date_sunrise and date_sunset. This means that one seems to get a timestamp, but this isn't a timestamp. And with the other bugreport there seems to be a logic error, not a timestamp error. As before, when I use both functions I aspect to get a timestamp back for witch the timezone is GMT* and not in the timezone for witch I added the offset to the functions... *As is normal with a timestamp Previous Comments: [2005-07-13 07:45:56] [EMAIL PROTECTED] Duplicate of: #32820 [2005-07-13 02:35:59] golf at dds dot nl I have also swaped lat and long and this solves my basic problem that the hours where wrong, but one can say that the bug is still there since my first suspision is correct, GMT offset is not used to calculate anything, it changes the timestamp to something that looks and feels like a timestamp but isn't since it isn't a GMT date/time combo but the GMT date/time combo + the offset. Since this isn't standard for timestamp I changed the status of this Bug to open... The algorithm looks to work acourding to this: http://williams.best.vwh.net/sunrise_sunset_algorithm.htm Where one can read the last line to see it is just added... My objection to the way the functions work probably won't make a change list, but it is something to add as a note to the manual becouse it is confusing (At least to me and perhaps more people). [2005-07-13 01:08:22] golf at dds dot nl After re-reading the source in the bug-report I now see that I passed $long and $lat where I should have passed $longitude, $latitude. I changed the code and now every thing seems oke... Sorry for the hassle made by this report but I realy missed this typo. Regards, Golf P.S. I tryd to add a comment to this bugreport (twice) but it didn't show up, so if there are more than one... [2005-07-13 00:53:07] golf at dds dot nl Description: With my current version of PHP5 (5.0.4-0.6.sarge.1 (Debian GNU/Linux) I run into an error if I use date_sunrise and date_sunset. This happens when I pass an GMT offset and results in a timestamp that has an offset of +1 hour to the actual sun set/rise on that date. Since timestamps are GMT/UTC and not bound to an timezone other that GMT/UTC this is wrong. I say this since I believe the GMT offset one can pass to the before mentioned functions is used in the calculation and the functions should return a timestamp like any other so it can be used by date and gmdate as those functions require a GMT/UTC timestamp... B.t.w. I use the max difference for some further calculations in my script, so there for the lage difference between astro and official sunset's/rises... Reproduce code: --- $latitude = 28 + (1/60*17) + (1/60/60*54); $longitude = (-(16 + (1/60*30) + (1/60/60*34))); $astro = 108; $official = (90 + (1/60*50)); echo "Local Tenerife time\n"; echo "sunriseAstro = " . gmdate("M d Y H:i:s", date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . "\n"; echo "sunriseOffical = " . gmdate("M d Y H:i:s", date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official , 1) + 60*60) . "\n"; echo "sunsetOffical = " . gmdate("M d Y H:i:s", date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official, 1) + 60*60) . "\n"; echo "sunsetAstro = " . gmdate("M d Y H:i:s", date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . "\n"; Expected result: Local Tenerife time sunriseAstro = Jul 12 2005 05:47:50 sunriseOffical = Jul 12 2005 07:02:02 sunsetOffical = Jul 12 2005 19:09:17 sunsetAstro = Jul 12 2005 20:23:27 Actual result: -- Local Tenerife time sunriseAstro = Jul 12 2005 06:47:50 sunriseOffical = Jul 12 2005 08:02:02 sunsetOffical = Jul 12 2005 20:09:17 sunsetAstro = Jul 12 2005 21:23:27 -- Edit this bug report at http://bugs.php.net/?id=33671&edit=1
#29724 [Com]: PHP Encountered an Access Violation
ID: 29724 Comment by: andrej at seznam dot org Reported By: bojo at gvea dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 2003 Server PHP Version: 5.0.1 New Comment: This error is following me on 3 different server configs, from php 4 version on. I encountered this error on combination of: - Windows server (XP, 2000 server, 2003 server) - IIS 5.0, 5.1 and 6.0 - PHP from 4 to latest 5.1.0b2 - MySQL from versions 4.0.x to latest 5.0.7 beta3 Finally, I was able to reproduce the bug and eliminate it! But only in one single case: This PHP code produced Access Violation; It is only weird, that the EXACT THE SAME code worked without problems for months, but then, suddenly, it begins constantly producing Access Violation error: for($i=0;$i<$rows;$i++) { $sqls="UPDATE sms_log SET delivered_date=\"$delivered_date[$i]\", send_date=\"$send_date[$i]\", delivered_status=\"$state[$i]\" WHERE msg_id=\"$msg_id[$i]\" AND to_user RLIKE $to_user[$i]"; $rs=mysql_query($sqls); } Now, I only changed the UPDATE to UPDATE LOW_PRIORITY, and Error was gone! Notise the only difference of UPDATE priorite switch: for($i=0;$i<$rows;$i++) { $sqls="UPDATE LOW_PRIORITY sms_log SET delivered_date=\"$delivered_date[$i]\", send_date=\"$send_date[$i]\", delivered_status=\"$state[$i]\" WHERE msg_id=\"$msg_id[$i]\" AND to_user RLIKE $to_user[$i]"; $rs=mysql_query($sqls); } The only concern I have is that the whole loop of queries took quite a long time to execute, even if they were executed in some other PHP application. I did tests with phpMyAdmin program, and inserted the whole bunch of about 50 queries from the mentioned loop into SQL query textbox. It took around a minute to execute! BUT if I executed the SAME bunch of queries from the command prompt, directly to MySQL, it executed in a second! THEREFORE it is NOT MySQL issue, but is related to how PHP executes MySQL statements. It might me php_mysql.dll library, might be libmysql.dll, or PHP core itself. Hope this would help with determining the cause of this wide spread and unpredictable error. Previous Comments: [2004-09-04 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". [2004-08-18 02:29:50] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2004-08-18 00:44:45] bojo at gvea dot com Description: The original bug found in PHP 5.0.0, referenced here: http://bugs.php.net/bug.php?id=29127 was never actually resolved. PHP 5.0.1 continues to give the following error under IIS 6.0 on Windows 2003 Server: PHP has encountered an Access Violation at [random memory address]. Expected result: Page processes completely. Actual result: -- Program bails with the following error: PHP has encountered an Access Violation at [random memory address] -- Edit this bug report at http://bugs.php.net/?id=29724&edit=1
#33698 [Bgs->Sus]: Conflicts with multiple interfaces sharing common method names
ID: 33698 Updated by: [EMAIL PROTECTED] Reported By: jason at hybd dot net -Status: Bogus +Status: Suspended Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.4 New Comment: FWIW, I agree; I think our interface support is pretty crappy because of this. I'm changing this to suspended status, because maybe one day it will appear, it's just not possible at the moment. Previous Comments: [2005-07-15 13:57:10] jason at hybd dot net I know PHP != Java, but surely this sort of stuff should be documented? Most people will expect interfaces to work like Java interfaces or C++ "interfaces" (Pure virtual abstract methods), as many other languages seem to follow this behaviour. As I said this is debatable as it depends how you look at things, and likewise it is fairly easy to work round this issue. [2005-07-15 12:44:04] [EMAIL PROTECTED] PHP != Java [2005-07-14 17:35:15] jason at hybd dot net Description: This is debateable if this is a bug or not. Personally, I don't regard it as a bug. Classes that implement >1 interface that share common methods raise fatal errors. Because of the abstract nature of interfaces, no error or warning should be rasied. I know PHP <> Java, but Java doesn't raise any errors, and PHP5's OO model is very close to Java's Reproduce code: --- interface FirstInterface { function execute(); } interface SecondInterface { function execute(); } class MyClass implements FirstInterface, SecondInterface { function execute() { echo "Hello World"; } } $obj = new MyClass(); $obj->execute(); Expected result: Hello World Actual result: -- Can't inherit abstract function SecondInterface::execute() -- Edit this bug report at http://bugs.php.net/?id=33698&edit=1
#33698 [Bgs]: Conflicts with multiple interfaces sharing common method names
ID: 33698 User updated by: jason at hybd dot net Reported By: jason at hybd dot net Status: Bogus Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.4 New Comment: I know PHP != Java, but surely this sort of stuff should be documented? Most people will expect interfaces to work like Java interfaces or C++ "interfaces" (Pure virtual abstract methods), as many other languages seem to follow this behaviour. As I said this is debatable as it depends how you look at things, and likewise it is fairly easy to work round this issue. Previous Comments: [2005-07-15 12:44:04] [EMAIL PROTECTED] PHP != Java [2005-07-14 17:35:15] jason at hybd dot net Description: This is debateable if this is a bug or not. Personally, I don't regard it as a bug. Classes that implement >1 interface that share common methods raise fatal errors. Because of the abstract nature of interfaces, no error or warning should be rasied. I know PHP <> Java, but Java doesn't raise any errors, and PHP5's OO model is very close to Java's Reproduce code: --- interface FirstInterface { function execute(); } interface SecondInterface { function execute(); } class MyClass implements FirstInterface, SecondInterface { function execute() { echo "Hello World"; } } $obj = new MyClass(); $obj->execute(); Expected result: Hello World Actual result: -- Can't inherit abstract function SecondInterface::execute() -- Edit this bug report at http://bugs.php.net/?id=33698&edit=1
#33707 [Asn]: Errors in select statements not reported
ID: 33707 Updated by: [EMAIL PROTECTED] Reported By: mangst at inventec dot ch Status: Assigned Bug Type: PDO related Operating System: Windows 2000 PHP Version: 5CVS-2005-07-14 (dev) Assigned To: wez New Comment: Ah, I misread the report. PDO::query() should report an error here of course. Previous Comments: [2005-07-15 08:20:07] [EMAIL PROTECTED] >I don't view this as a bug. You can't reproduce it? I can. >We report errors when the driver tells us there are errors; > PDO isn't doing anything wrong, per se. But there was an error, it's just hidden. This code works fine: prepare('select blah from dual'); $rs = $st->execute(); var_dump($rs); var_dump($st->errorInfo()); ?> And this doesn't (only with OCI): query('select blah from dual'); var_dump($rs); var_dump($db->errorInfo()); ?> This happens because with MySQL it fails on prepare stage, but OCI passes prepare and fails only while executing the statement, so the error goes to the statement handle. [2005-07-14 23:58:04] [EMAIL PROTECTED] I don't view this as a bug. We report errors when the driver tells us there are errors; PDO isn't doing anything wrong, per se. I also don't see how copying the errors up from the statement to the dbh when execute() is called will help either. [2005-07-14 23:37:35] [EMAIL PROTECTED] That happens because Oracle's OCIStmtPrepare() doesn't validate the query, it just allocates/prepares stmt handle for execution. Then PDO happily executes this statement and all errors go to the stmt handle (which is destroyed right after that). Wez, from what I can see, with OCI we should always copy einfo struct from the stmt handle to the dbh handle if stmt's execution failed. Thoughts? [2005-07-14 22:07:02] mangst at inventec dot ch Description: When a SQL statement is executed with PDO::query, PDO::errorInfo[0] always reports "0" even when an error has occurred and PDO::query returned . Reproduce code: --- getMessage()); } $rs = $db->query('select nvarchar(8) from dual'); echo 'Statement handle: '; var_dump($rs); echo "\r\nError info of database handle: "; var_dump($db->errorInfo()); $db = null; ?> Expected result: Somthing like: Statement handle: bool(false) Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=> "" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"} Actual result: -- Statement handle: bool(false) Error info of database handle: array(1) { [0]=> string(5) "0" } -- Edit this bug report at http://bugs.php.net/?id=33707&edit=1
#33648 [Csd->Asn]: Using --with-regex=system causes compile failure
ID: 33648 Updated by: [EMAIL PROTECTED] Reported By: ergin at ergin dot dyndns dot org -Status: Closed +Status: Assigned Bug Type: Compile Failure Operating System: * PHP Version: 5CVS, 4CVS (2005-07-12) Assigned To: andrei New Comment: This is not fixed yet. I added the necessary configure checks and now HAVE_REGEX_T_RE_MAGIC is defined if re_magic exists in regext_t struct. Andrei: Please check it out. Previous Comments: [2005-07-14 22:25:38] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-07-12 15:41:55] [EMAIL PROTECTED] Assigned to Andrei, he broke it. As to the problem: remove --with-regex=system from your configure line and it will work fine. [2005-07-12 08:56:25] ergin at ergin dot dyndns dot org Here is my configure line... - START - %configure \ --prefix=%{_prefix} \ --with-config-file-path=%{_sysconfdir} \ --enable-force-cgi-redirect \ --disable-debug \ --enable-pic \ --disable-rpath \ --enable-inline-optimization \ --with-dom=shared \ --with-bz2 \ --with-db3 \ --with-exec-dir=%{_bindir} \ --with-freetype-dir=%{_prefix} \ --with-gd \ --with-gdbm \ --with-gettext \ --with-gmp \ --with-jpeg-dir=%{_prefix} \ --with-mm \ --with-openssl \ --with-png \ --with-regex=system \ --with-ttf \ --with-xml \ --with-expat-dir=%{_prefix} \ --with-zlib \ --with-layout=GNU \ --enable-bcmath \ --enable-debugger \ --enable-ftp \ --enable-magic-quotes \ --enable-safe-mode \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-discard-path \ --enable-mime-magic \ --enable-track-vars \ --enable-trans-sid \ --enable-yp \ --enable-wddx \ --without-oci8 \ --with-iconv --enable-mbstring --enable-mbregex \ --with-imap=shared,/usr/local/src/imap-2002e --with-imap-ssl --with-kerberos=/usr/kerberos \ --with-ldap=shared \ --with-mysql=shared,/usr \ --with-pgsql=shared \ --with-curl=shared \ --with-mcrypt=shared \ --with-snmp=%{_prefix} \ --with-snmp=shared \ --enable-ucd-snmp-hack \ --with-unixODBC=shared \ --with-xmlrpc=shared \ --with-mhash=shared \ --enable-memory-limit \ --enable-bcmath \ --enable-shmop \ --enable-versioning \ --enable-sockets --enable-pcntl --enable-sigchild \ $* END -- [2005-07-11 22:38:14] ergin at ergin dot dyndns dot org Description: Got following message when I tried to build RPMS for new PHP version php-4.4.0 (OBS!!! couldn't choose it from drop menu - PHP version) . Actual result: -- /usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c: In fucntion '_php_regcomp': /usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:53 structure has no member named 're_magic' /usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:72 structure has no member named 're_magic' make *** [ext/standard/reg.lo] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.66063 -- Edit this bug report at http://bugs.php.net/?id=33648&edit=1
#31132 [Com]: Installing PHP 5.0.3 causes 403.9 HTTP Errors under IIS 5
ID: 31132 Comment by: webwire at zonnet dot nl Reported By: aaron at visualprose dot com Status: No Feedback Bug Type: IIS related Operating System: Windows XP Professional SP 1 PHP Version: 5.0.3 New Comment: I can confirm: The problem is solved on the newest CVS version. Previous Comments: [2005-03-15 18:03:19] mailkabin at yahoo dot com Can't Configure the PHP version 5.0 in Win2003 System. .. Operation System : Windows Server 2003 IIS Ver : 6.0 Other Installed Comp: ASP / ASP .net . Problem : Displays the "Page Cannot be displayed Page." or "File Not Found Page." [2005-03-10 01:00:05] 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". [2005-02-28 21:14:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-12-16 18:49:38] aaron at visualprose dot com Description: When PHP 5.0.3 is installed under IIS 5.0 on Windows XP Professional, all web pages (.html, .php, .asp, or .aspx) can only be viewed ten times before IIS reports "HTTP 403.9 - Access Forbidden: Too many users are connected". No pages (inlcluding HTML, ASP, etc.) can be viewed once this error occurs. IIS must be restarted (which takes approximately 5 minutes). I have followed the steps on Microsoft's site to disable HTTP Keep-alives, and the problem persists. Removing the script map to PHP solves the problem, which is what leads me to believe PHP is causing the problem Reproduce code: --- 1) Install PHP 5.0.3 on Windows XP SP 1. 2) Load up a .html, .php, or .asp running on the web server. 3) Hit "Refresh" 10 times. 4) Note the 403.9 HTTP error appears. Note that IIS must be restarted before access to any resource is allowed again. Expected result: No 403.9 error. Actual result: -- IIS continues to give the 403.9 error page until it is restarted. -- Edit this bug report at http://bugs.php.net/?id=31132&edit=1
#33698 [Opn->Bgs]: Conflicts with multiple interfaces sharing common method names
ID: 33698 Updated by: [EMAIL PROTECTED] Reported By: jason at hybd dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.0.4 New Comment: PHP != Java Previous Comments: [2005-07-14 17:35:15] jason at hybd dot net Description: This is debateable if this is a bug or not. Personally, I don't regard it as a bug. Classes that implement >1 interface that share common methods raise fatal errors. Because of the abstract nature of interfaces, no error or warning should be rasied. I know PHP <> Java, but Java doesn't raise any errors, and PHP5's OO model is very close to Java's Reproduce code: --- interface FirstInterface { function execute(); } interface SecondInterface { function execute(); } class MyClass implements FirstInterface, SecondInterface { function execute() { echo "Hello World"; } } $obj = new MyClass(); $obj->execute(); Expected result: Hello World Actual result: -- Can't inherit abstract function SecondInterface::execute() -- Edit this bug report at http://bugs.php.net/?id=33698&edit=1
#33704 [Opn->Bgs]: similar to bug#19804
ID: 33704 Updated by: [EMAIL PROTECTED] Reported By: jokar30 at hotmail dot com -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: sparc solaris 9 PHP Version: 5.0.3 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. Previous Comments: [2005-07-14 22:05:35] jokar30 at hotmail dot com Thank you for your reply... That means I should use mcrypt and not libmcrypt? In this case, I should use ./configure' '--with-mcrypt=/opt/mcrypt-x.y.z' '--with-mhash=/opt/php-5.0.4/ext/mhash' '--with-apxs=/usr/apache/bin/apxs' ??? [2005-07-14 21:27:49] [EMAIL PROTECTED] 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. And it doesn't make sense, as mcrypt now has all their modules builtin anyway so you don't need those directores. I guess you installed libmcrypt incorrectly. [2005-07-14 20:05:50] jokar30 at hotmail dot com Description: Hello, I have done nearly everything and I still get the supported ciphers and supported modes = none on the phpinfo(). I have set mcrypt.algorithms_dir = /opt/libmcrypt-2.5.6/modules/algorithms/ mcrypt.modes_dir = /opt/libmcrypt-2.5.6/modules/modes/ I have changed the chmod 755 to /usr/local/lib/libmcrypt I have cofigured php5.0.4 with ./configure' '--with-mcrypt=/opt/libmcrypt-2.5.6' '--with-mhash=/opt/php-5.0.4/ext/mhash' '--with-apxs=/usr/apache/bin/apxs' Any help would be appreciated ;-) Thank you -- Edit this bug report at http://bugs.php.net/?id=33704&edit=1
#33708 [Fbk->Opn]: Problem with php module recode
ID: 33708 User updated by: kirameku at email dot cz Reported By: kirameku at email dot cz -Status: Feedback +Status: Open Bug Type: Recode related Operating System: RedHat ES4 x86_64 PHP Version: 4.4.0 New Comment: -- System Information: RedHat ES4 (x86_64) Architecture: x86_64 Kernel: 2.6.9-11.ELsmp I have php4 compiled with "./configure .. --enable-recode --with-recode ...". When I do $ /usr/bin/php ./test.php Segmentation fault and test.php : I first tought it was a bug on librecode but it works well from the command line : echo "Hello, World"|recode "utf-8..html_4.0" Hello, World Previous Comments: [2005-07-14 22:22:07] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-07-14 22:20:38] kirameku at email dot cz Description: Problem with php module recode on platform x86_64. recode ( string request, string string ) => Segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=33708&edit=1
#33692 [Opn]: imagettftext produces no output
ID: 33692 User updated by: a dot vent at procommerz dot de Reported By: a dot vent at procommerz dot de Status: Open Bug Type: GD related Operating System: Debian Linux 3.0 "Woody" PHP Version: 4.4.0 New Comment: Additional note: After further dealing with this issue I found that imagettftext works fine on 8 bit images (when using "imagecreate" instead of "imagecreatetruecolor"), but not on true color images. There is a workaround proposal published by "persa" (http://www.webdeveloper.com/forum/showthread.php?threadid=30767) that is to create two images (one of them at 8 bit) and then merging them together after putting the text onto the 8 bit image. It actually seems to be a bug, doesn't it? Best regards, Andreas Previous Comments: [2005-07-14 09:50:28] a dot vent at procommerz dot de Description: The ImageTTFText function produces no result, but also no error. I've tried several font files (Microsoft TT core fonts and also from other sources), several paths (the same dir as the PHP script, relative to DocRoot, absolute path a.s.o.). It looks like not calling imagettftext - the function silently does nothing... I have Debian "Woody" with Apache 1.3.29 / PHP 4.4.0. The GD lib is the bundled one (phpinfo says: "2.0.28 compatible"). The Freetype lib version is 1.4pre, as provided from Debian package manager. PHP configure options: './configure' '--with-apxs=/var/www/bin/apxs' '--with-mysql' '--enable-ftp' '--enable-shared' '--with-iconv' '--with-gd' '--with-curl' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-dom=/usr' '--with-zlib' '--enable-cli' '--with-ttf=/usr' Output snippet from phpinfo: GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Support enabled FreeType Linkage with TTF library GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XBM Support enabled Reproduce code: --- Expected result: Displays an image with white-colored text "Hello World" in Arial font face on grey background. Actual result: -- Displays an grey-colored image without any text (empty grey box). No error messages. -- Edit this bug report at http://bugs.php.net/?id=33692&edit=1
#33635 [Asn]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Assigned Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) Assigned To: georg New Comment: This problem only occurs when writing out session data to a database when the script terminates, and also because I am using a shared database connection (the one created when the session data was forst read in). I conducted a little experiment by replacing the exit function with session_write_close(), and this did not produce the error. I therefore strongly suspect that the order of events at script termination has been altered to: (a) close all resources (b) write session data (to database) This will fail if (b) uses a resource closed in (a) Previous Comments: [2005-07-12 01:08:12] [EMAIL PROTECTED] Assigned to the author of the extension, who can propably explain this better.. [2005-07-11 23:55:55] tony at marston-home dot demon dot co dot uk You are completely mistaken. I am not mixing both OO and procedural ways of accessing the DB - all my calls to the mysqli_* functions are in the procedural style. The fact that I am making these calls inside my own OO class should be totally irrelevant. The same code has worked perfectly through php 5.0.0 to 5.0.4, and with 5.0.5-dev only fails when I try to write my session data to the database. SOMETHING HAS BEEN INTRODUCED IN 5.0.5-dev THAT CAUSES THIS FAILURE. My use of static variables follows the documentation for the singleton pattern at http://www.php.net/manual/en/language.oop5.patterns.php. It allows to to call mysqli_connect() only once for a request. [2005-07-11 22:48:09] [EMAIL PROTECTED] Please read the friendly manual about Mysqli. You're trying to mix both OO and procedural way of accessing the DB. Choose one and stick to that. (And I don't get the idea of making the connection 'static' either..especially if you deal with OOP) [2005-07-11 12:33:45] tony at marston-home dot demon dot co dot uk Whoops. That URL should be http://www.tonymarston.net/test.zip [2005-07-11 11:59:48] tony at marston-home dot demon dot co dot uk I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (=& with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.zip 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1