#39221 [Com]: php5ts.dll faulting every few minutes on apache2.2
ID: 39221 Comment by: paradiso at gmail dot com Reported By: kris at k-software dot org Status: No Feedback Bug Type: Apache2 related Operating System: windows server 2003 x64 PHP Version: 5CVS-2006-10-20 (snap) New Comment: This is really a bug. on my p4 2.4c + 865G + 1G ram, win2k3 server, apache 2.2.3.0 & php 5.2, this happens all the time. Previous Comments: [2006-10-31 01:00:01] 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". [2006-10-22 14:14:23] kris at k-software dot org Error in CPU IDs in previous comment, from microsoft support article ID 252867: Processor enumeration on computers that use hyperthreading first assign processor numbers to the primary logical processor for each processor and then assign numbers to the secondary. For example, for dual physical processor computers with hyperthreading, the first processor has logical processor 0 and 2, and the second processor has logical processor 1 and 3. [2006-10-22 13:59:13] kris at k-software dot org It appears that setting the CPU affinity of the apache http process to a single physical processor stops the crashing... Setting the server to NOT use the second hyperthreaded core of the xeons (i.e. CPUs 0+2 or 1+3) seems to solve this random crashing. Will test with a prefork MPM. [2006-10-22 12:49:58] kris at k-software dot org I'm currently unable to track down a single script/function which causes this error, and am therefore unable to provide a code sample. I realise that the bug report is pretty useless without reproducable code, so I'm still investigating and trying to track down the exact cause of the crashes. [2006-10-21 20:38:21] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. 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/39221 -- Edit this bug report at http://bugs.php.net/?id=39221&edit=1
#39409 [Opn->Bgs]: loadhtml problem when html contains javascript that contain tag in string var
ID: 39409 Updated by: [EMAIL PROTECTED] Reported By: c00lways at gmail dot com -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: windows 2000 PHP Version: 5.2.0 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 html parsing is done by libxml2, so you should complain there. Or just use like in the old days :) Previous Comments: [2006-11-07 03:30:55] c00lways at gmail dot com Description: odd problem with javascript which contains tag within the string, example: ---
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: xangelusx at hotmail dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: Still having trouble on Windows 2003 with 5.2 (stable)! (See my previous comment for details) Previous Comments: [2006-10-19 23:19:43] sbugs6 at yahoo dot fr With PHP 5.2.0RC6-dev (Oct 19 2006 20:17:20) on WinXP-SP2 [2006-10-11 02:31:30] snoopspecial at hotmail dot com I have the same problem using Windows 2003 SP1 and PHP 5.1.6 I tried the output buffering = 1000 and no luck either. please fix! [2006-10-05 02:51:36] xangelusx at hotmail dot com I confirmed the problem using msisolak's test on a Win 2003 server with PHP 5.1.6 running under fastcgi. Same on a Windows 2000 server with same PHP config. [2006-09-28 17:34:44] randy at rcs-comp dot com I am requesting that this bug status be changed to "open" since there has been plenty of feedback and until the bug has been confirmed to be fixed. I have also run into this same issue with php > 5.1.4 including the latest 5.1 snapshot. My solution was to use 5.1.2 instead. [2006-09-07 14:12:36] robert dot sevcik at gmail dot com I'm sorry for spamming, but I went a step further, downgraded to PHP Version 5.1.0-dev and the FastCGI has no problem. Build date Jun 21 2005 12:21:48 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/37448 -- Edit this bug report at http://bugs.php.net/?id=37448&edit=1
#39409 [NEW]: loadhtml problem when html contains javascript that contain tag in string var
From: c00lways at gmail dot com Operating system: windows 2000 PHP version: 5.2.0 PHP Bug Type: DOM XML related Bug description: loadhtml problem when html contains javascript that contain tag in string var Description: odd problem with javascript which contains tag within the string, example: ---
#39352 [Com]: oci_close fails with global keyword
ID: 39352 Comment by: anon at anon dot com Reported By: david at acz dot org Status: Assigned Bug Type: OCI8 related Operating System: SuSE Linux 9.3 PHP Version: 5.2.0 Assigned To: tony2001 New Comment: reproduced on Windows 2003 server, using Nov 2 release of 5.2.0 Previous Comments: [2006-11-02 22:54:38] david at acz dot org Description: oci_close() fails if the connection resource is a global accessed via the "global" keyword, but works if accessed using the $GLOBALS array. Reproduce code: --- $conn = oci_connect(DB_USER, DB_PASS, DB_NAME); var_dump($conn); global_keyword(); global_array(); function global_keyword() { global $conn; var_dump($conn); oci_close($conn); // this seems to do nothing var_dump($conn); } function global_array() { var_dump($GLOBALS["conn"]); oci_close($GLOBALS["conn"]); // this works var_dump($GLOBALS["conn"]); } Expected result: resource(8) of type (oci8 connection) resource(8) of type (oci8 connection) NULL NULL PHP Warning: oci_close() expects parameter 1 to be resource, null given NULL Actual result: -- resource(8) of type (oci8 connection) resource(8) of type (oci8 connection) resource(8) of type (oci8 connection) resource(8) of type (oci8 connection) NULL -- Edit this bug report at http://bugs.php.net/?id=39352&edit=1
#39408 [NEW]: the Implements keyword
From: allen dot arbeau at gmail dot com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Class/Object related Bug description: the Implements keyword Description: I am using PHP 5.2.0, Dreamweaver 8 and IE 7. I receive an error on the webpage pointing to my TextBox class (line 5) when I attempt to use the keyword "implements" in that class. Reproduce code: --- (The line numbers are for reference only and are not actually in the class.) --Element.php 1 - --TextBox.php 1 - Expected result: I expect the application to recognize the keyword "implements" as a valid keyword. In the case of Dreamweaver it should color code the word "interface" as a keyword but it does not which suggests it does not recognize "implements" as a valid keyword such as "extends" or "class". Actual result: -- I get the error: "Parse error: syntax error, unexpected T_STRING, expecting T_VARIABLE in subscribers_kiosk/baseclass/TextBox.php on line 5" on the webpage when I try to include the "TextBox.php" page into any other php page. -- Edit bug report at http://bugs.php.net/?id=39408&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39408&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39408&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39408&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39408&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39408&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39408&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39408&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39408&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39408&r=support Expected behavior:http://bugs.php.net/fix.php?id=39408&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39408&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39408&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39408&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39408&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39408&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39408&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39408&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39408&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39408&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39408&r=mysqlcfg
#39407 [NEW]: Swapped Upload and Session Directory
From: eoghan at loggedin dot com Operating system: XP SP2 PHP version: 5.2.0 PHP Bug Type: IIS related Bug description: Swapped Upload and Session Directory Description: When you run the windows installer and choose IIS4+ CGI, it seems to swap the values for the session directory and the uploads directory in the php.ini file when it's created. In php.ini it has upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session" session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload" and I think they're probably meant to be swapped i.e. upload_tmp_dir="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\upload" session.save_path="C:\DOCUME~1\Eoghan\LOCALS~1\Temp\php\session" Not a biggie, probably wouldn't really stop things functioning in most cases, but just thought you might want to know. Eoghan. -- Edit bug report at http://bugs.php.net/?id=39407&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39407&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39407&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39407&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39407&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39407&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39407&r=support Expected behavior:http://bugs.php.net/fix.php?id=39407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39407&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39407&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39407&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39407&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39407&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39407&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39407&r=mysqlcfg
#39405 [Opn->Bgs]: regular expression breaking on strings >= 24999 characters
ID: 39405 User updated by: spam at dragy dot de Reported By: spam at dragy dot de -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Any PHP Version: 5.2.0 New Comment: pcre.backtrack_limit=-1 in php.ini Previous Comments: [2006-11-06 20:48:02] ludvig dot ericson at gmail dot com This is because of limits intentionally set, see the ini setting pcre.backtrack_limit. [2006-11-06 18:45:23] spam at dragy dot de Description: The following preg_replace breaks when the string is => 24999 characters. Works perfectly fine with 24998 characters and worked fine with any strings in PHP 5.1.5. Reproduce code: --- Expected result: 100.000 times 'a' Actual result: -- nothing -- Edit this bug report at http://bugs.php.net/?id=39405&edit=1
#39405 [Com]: regular expression breaking on strings >= 24999 characters
ID: 39405 Comment by: ludvig dot ericson at gmail dot com Reported By: spam at dragy dot de Status: Open Bug Type: PCRE related Operating System: Any PHP Version: 5.2.0 New Comment: This is because of limits intentionally set, see the ini setting pcre.backtrack_limit. Previous Comments: [2006-11-06 18:45:23] spam at dragy dot de Description: The following preg_replace breaks when the string is => 24999 characters. Works perfectly fine with 24998 characters and worked fine with any strings in PHP 5.1.5. Reproduce code: --- Expected result: 100.000 times 'a' Actual result: -- nothing -- Edit this bug report at http://bugs.php.net/?id=39405&edit=1
#39406 [Opn]: Wrong namespaces in SOAP request
ID: 39406 User updated by: mail at martin-probst dot com Reported By: mail at martin-probst dot com Status: Open Bug Type: SOAP related Operating System: MacOS PHP Version: 5.2.0 New Comment: Btw.: Bug #36547 seems related And: http://de3.php.net/manual/en/ref.soap.php#69173 seems to refer to the same bug, providing a really weird and dirty work-around. Previous Comments: [2006-11-06 20:03:36] mail at martin-probst dot com Description: I'm trying to access a web service using a .wsdl file, literal style. The wsdl defines two schemata with different namespaces where the first one refers to the latter. The message parameter in the SOAP envelope gets the wrong namespace. Reproduce code: --- The wsdl contains two schemata: http://www.w3.org/2001/XMLSchema"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS"; targetNamespace="http://targetNS";> http://otherNS"/> ... http://www.w3.org/2001/XMLSchema"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS"; xmlns="http://otherNS"; targetNamespace="http://otherNS";> ... The calling PHP code: $res = $soap->EmployeeBasicDataByEmployeeQueryResponse_In( array("EmployeeBasicDataSelectionByEmployee" => array("EmployeeID" => 10; echo $soap->__getLastRequest() . "\n"; I also tried classmaps and various array combinations. If you add another array level (EmployeeBasicDataByEmployeeQuery) the above gives an error (object hasn't 'EmployeeBasicDataSelectionByEmployee' property). Expected result: http://schemas.xmlsoap.org/ soap/envelope/" xmlns:ns1="http://targetNS"; xmlns:ns2="http://otherNS";> 10 Actual result: -- http://schemas.xmlsoap.org/ soap/envelope/" xmlns:ns1="http://my/namespace/somewhere";> 10 -- Edit this bug report at http://bugs.php.net/?id=39406&edit=1
#39406 [NEW]: Wrong namespaces in SOAP request
From: mail at martin-probst dot com Operating system: MacOS PHP version: 5.2.0 PHP Bug Type: SOAP related Bug description: Wrong namespaces in SOAP request Description: I'm trying to access a web service using a .wsdl file, literal style. The wsdl defines two schemata with different namespaces where the first one refers to the latter. The message parameter in the SOAP envelope gets the wrong namespace. Reproduce code: --- The wsdl contains two schemata: http://www.w3.org/2001/XMLSchema"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS"; targetNamespace="http://targetNS";> http://otherNS"/> ... http://www.w3.org/2001/XMLSchema"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"; xmlns:xi0="http://targetNS"; xmlns:xi1="http://otherNS"; xmlns="http://otherNS"; targetNamespace="http://otherNS";> ... The calling PHP code: $res = $soap->EmployeeBasicDataByEmployeeQueryResponse_In( array("EmployeeBasicDataSelectionByEmployee" => array("EmployeeID" => 10; echo $soap->__getLastRequest() . "\n"; I also tried classmaps and various array combinations. If you add another array level (EmployeeBasicDataByEmployeeQuery) the above gives an error (object hasn't 'EmployeeBasicDataSelectionByEmployee' property). Expected result: http://schemas.xmlsoap.org/ soap/envelope/" xmlns:ns1="http://targetNS"; xmlns:ns2="http://otherNS";> 10 Actual result: -- http://schemas.xmlsoap.org/ soap/envelope/" xmlns:ns1="http://my/namespace/somewhere";> 10 -- Edit bug report at http://bugs.php.net/?id=39406&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39406&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39406&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39406&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39406&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39406&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39406&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39406&r=support Expected behavior:http://bugs.php.net/fix.php?id=39406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39406&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39406&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39406&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39406&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39406&r=mysqlcfg
#39405 [NEW]: regular expression breaking on strings >= 24999 characters
From: spam at dragy dot de Operating system: Any PHP version: 5.2.0 PHP Bug Type: PCRE related Bug description: regular expression breaking on strings >= 24999 characters Description: The following preg_replace breaks when the string is => 24999 characters. Works perfectly fine with 24998 characters and worked fine with any strings in PHP 5.1.5. Reproduce code: --- Expected result: 100.000 times 'a' Actual result: -- nothing -- Edit bug report at http://bugs.php.net/?id=39405&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39405&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39405&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39405&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39405&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39405&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39405&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39405&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39405&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39405&r=support Expected behavior:http://bugs.php.net/fix.php?id=39405&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39405&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39405&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39405&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39405&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39405&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39405&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39405&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39405&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39405&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39405&r=mysqlcfg
#39401 [Fbk->Opn]: conflicting types for utf8_mime2text
ID: 39401 User updated by: wouter at widexs dot nl Reported By: wouter at widexs dot nl -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: Yes, it does :) grep "mail_append_set" src/c-client/mail.h SEARCHSET *mail_append_set (SEARCHSET *set,unsigned long msgno); Previous Comments: [2006-11-06 17:01:26] [EMAIL PROTECTED] Does your imap's mail.h header contain the mail_append_set() function? [2006-11-06 15:23:14] wouter at widexs dot nl Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#38976 [Com]: missing last character when fetching query
ID: 38976 Comment by: jason at southerntextile dot com Reported By: zolfi at parspooyesh dot com Status: No Feedback Bug Type: PDO related Operating System: fedora linux 5 PHP Version: 5.1.6 New Comment: Latest Fedora RPMs (compilied Nov. 2) still affected by bug. Previous Comments: [2006-10-27 21:23:44] jason at southerntextile dot com Make that two differnt Fedora 6 servers with the same problem now (PHP 5.1.6 /w PDO). [2006-10-27 20:04:45] jason at southerntextile dot com Since doing a fresh install of Fedora 6. This is occuring on all my SQLite databases (using PDO). [2006-10-05 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-09-27 16:57:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Can't reproduce. [2006-09-27 16:52:29] zolfi at parspooyesh dot com Description: when using SELECT statement for selecting rows of table, and using fetchAll(or fetch) method the last character of each row will be lost. Reproduce code: --- $db_location = "table.sqlite"; $db = new PDO("sqlite:{$db_location}"); $db->query("create table my_table (name text);"); // table is empty $query = $db->query("delete from my_table"); $query = $db->query("insert into my_table (name) values ('123')"); $query = $db->query("select name from my_table"); while ($row = $query->fetch()) { print_r($row); } Expected result: Array ( [name] => 123 [0] => 123 ) Actual result: -- Array ( [name] => 12 [0] => 12 ) -- Edit this bug report at http://bugs.php.net/?id=38976&edit=1
#39350 [Opn->Csd]: Segfault with implode("\n", array(false))
ID: 39350 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at thequod dot de -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Ubuntu Linux PHP Version: 5CVS-2006-11-02 (CVS) 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: [2006-11-02 22:20:34] phpbugs at thequod dot de The crash can be reproduced "inline", by $b = trim($b); after the implode(). [2006-11-02 22:17:30] phpbugs at thequod dot de Description: When imploding/joining an array with only "false" in it, PHP segfaults (on shutdown?). I've found this in a more complex use case, where it segfaulted during execution, but probably because of this root problem. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208198976 (LWP 4071)] 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c "/usr/local/src/PHP_5_2/Zend/zend_variables.h", __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) bt #0 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c "/usr/local/src/PHP_5_2/Zend/zend_variables.h", __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 #1 0x083d02f8 in _zval_dtor (zvalue=0xb7ebd8ec, __zend_filename=0x86851e4 "/usr/local/src/PHP_5_2/Zend/zend_execute_API.c", __zend_lineno=414) at /usr/local/src/PHP_5_2/Zend/zend_variables.h:35 #2 0x083d04ba in _zval_ptr_dtor (zval_ptr=0xb7ebd92c, __zend_filename=0x8686238 "/usr/local/src/PHP_5_2/Zend/zend_variables.c", __zend_lineno=175) at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:414 #3 0x083dd92c in _zval_ptr_dtor_wrapper (zval_ptr=0xb7ebd92c) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:175 #4 0x083eb689 in zend_hash_apply_deleter (ht=0x86e2bb0, p=0xb7ebd920) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:606 #5 0x083eb80d in zend_hash_graceful_reverse_destroy (ht=0x86e2bb0) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:641 #6 0x083cff2b in shutdown_executor () at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:239 #7 0x083df05a in zend_deactivate () at /usr/local/src/PHP_5_2/Zend/zend.c:840 #8 0x0838b2fc in php_request_shutdown (dummy=0x0) at /usr/local/src/PHP_5_2/main/main.c:1300 #9 0x0845807b in main (argc=3, argv=0xbf81bf24) at /usr/local/src/PHP_5_2/sapi/cli/php_cli.c:1259 Reproduce code: --- Expected result: string(0) "" bar (PHP 5.1.6) Actual result: -- string(0) "" barSegmentation fault (core dumped) (PHP_5_2) -- Edit this bug report at http://bugs.php.net/?id=39350&edit=1
#39404 [Opn]: Support "entity" as substitute_character setting
ID: 39404 User updated by: martin dot t dot kutschker at blackbox dot net -Summary: Support "entitiy" as substitute_character setting Reported By: martin dot t dot kutschker at blackbox dot net Status: Open Bug Type:mbstring related PHP Version: 5.2.0 New Comment: Fix spelling of "entity" in the summary. Previous Comments: [2006-11-06 16:56:19] martin dot t dot kutschker at blackbox dot net Description: It would be great if the charset conversion could also output SGML/HTML entites for missing characters in the output charset. The option "long" is not very HTML-friendly. But with "entity" any Unicode aware browser could deal with the missing charater. eg mbstring.substitute_character=long => U+3000 mbstring.substitute_character=entity => -- Edit this bug report at http://bugs.php.net/?id=39404&edit=1
#39357 [Opn->Asn]: absent fault detail node
ID: 39357 Updated by: [EMAIL PROTECTED] Reported By: yaksenov at iponweb dot net -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: gentoo-linux PHP Version: 5.2.0 -Assigned To: +Assigned To: dmitry Previous Comments: [2006-11-03 11:18:32] yaksenov at iponweb dot net updated code to reproduce the behavior - client.pl added http://rapidshare.com/files/1796872/soap_fault_detail_post.tar.gz MD5: fde0f911544e2096c4e992d23b1df0e8 [2006-11-03 10:01:11] yaksenov at iponweb dot net Description: SoapFault->__construct() with 'faultname' causes wrong fault response: the node is absent. Reproduce code: --- http://rapidshare.com/files/1788815/soap_fault_detail_post.tar.gz Expected result: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:ns1="http://api.mymanager.com/types"; xmlns:ns2="urn:ContactService" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";> SOAP-ENV:Server always throw exception http://localhost/soap_fault_detail/contact.php access Actual result: -- http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:ns1="http://api.mymanager.com/types";> SOAP-ENV:Server always throw exception http://localhost/soap_fault_detail/contact.php access -- Edit this bug report at http://bugs.php.net/?id=39357&edit=1
#39401 [Opn->Fbk]: conflicting types for utf8_mime2text
ID: 39401 Updated by: [EMAIL PROTECTED] Reported By: wouter at widexs dot nl -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Linux PHP Version: 5.2.0 New Comment: Does your imap's mail.h header contain the mail_append_set() function? Previous Comments: [2006-11-06 15:23:14] wouter at widexs dot nl Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit this bug report at http://bugs.php.net/?id=39401&edit=1
#38051 [Com]: changing upload_max_filesize in php.ini has no effect
ID: 38051 Comment by: zavpublic at mac dot com Reported By: saurabh_barjatiya at daiict dot ac dot in Status: No Feedback Bug Type: *Configuration Issues Operating System: Fedora Core 5 PHP Version: 5.1.4 New Comment: Same issue for me in 5.1.4 Using php 5.1.4 in MAMP on a Quad G5 under Mac OS X 10.4.8. Previous Comments: [2006-07-18 01:00:01] 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". [2006-07-10 07:54:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Works just fine here. [2006-07-10 01:08:26] saurabh_barjatiya at daiict dot ac dot in Description: I have changed following in php.ini, Still when I run phpinfo() I get upload_max_filesize as 2M while other two getchanged. upload_max_filesize 2000M post_max_size 2000M memory_limit 2000M I have also tried creating php.ini in same directory as script with above settings. I have also tried creating .htaccess with php_value upload_max_filesize 2000M Still all scrips return 2M even with ini_get. Please check or tell how to change upload_max_filesize Reproduce code: --- Expected result: 2000M Actual result: -- 2M -- Edit this bug report at http://bugs.php.net/?id=38051&edit=1
#39404 [NEW]: Support "entitiy" as substitute_character setting
From: martin dot t dot kutschker at blackbox dot net Operating system: PHP version: 5.2.0 PHP Bug Type: mbstring related Bug description: Support "entitiy" as substitute_character setting Description: It would be great if the charset conversion could also output SGML/HTML entites for missing characters in the output charset. The option "long" is not very HTML-friendly. But with "entity" any Unicode aware browser could deal with the missing charater. eg mbstring.substitute_character=long => U+3000 mbstring.substitute_character=entity => -- Edit bug report at http://bugs.php.net/?id=39404&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39404&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39404&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39404&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39404&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39404&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39404&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39404&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39404&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39404&r=support Expected behavior:http://bugs.php.net/fix.php?id=39404&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39404&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39404&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39404&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39404&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39404&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39404&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39404&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39404&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39404&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39404&r=mysqlcfg
#39403 [NEW]: A class can't implements interface implemented by implemented interface/classes
From: baldurien at bbnwn dot eu Operating system: Irrelevant PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: A class can't implements interface implemented by implemented interface/classes Description: Hi, Since php5.2, all my classes have error due to something that changed in php5.2 : Fatal error: Class XtfLexer cannot implement previously implemented interface XtfParserRegistrable The reason of that ? Well take a look at the classes (the code does not interest you as it's not the problem) interface XtfParserRegistrable {} interface XtfHeaderHandler extends XtfParserRegistrable {} class XtfLexer implements XtfHeaderHandler, XtfParserRegistrable {} Because the interface extends XtfParserRegistrable, the XtfLexer can not implements XtfParserRegistrable itself. This is STUPID, REALLY STUPID. What happens if one day I change the interface/classes I implements/extends, and if I still wish to benefit from one interface that is *possibly* implemented by my parents interfaces/classes? Well : it will fails. Reproduce code: --- Try this : interface XtfParserRegistrable {} interface XtfHeaderHandler extends XtfParserRegistrable {} class XtfLexer implements XtfHeaderHandler, XtfParserRegistrable {} Expected result: We can implements interface implemented by parent class/interface, and no (fatal) error should be thrown. Actual result: -- We can't. -- Edit bug report at http://bugs.php.net/?id=39403&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39403&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39403&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39403&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39403&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39403&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39403&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39403&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39403&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39403&r=support Expected behavior:http://bugs.php.net/fix.php?id=39403&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39403&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39403&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39403&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39403&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39403&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39403&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39403&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39403&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39403&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39403&r=mysqlcfg
#39381 [Com]: __destruct bug
ID: 39381 Comment by: harveyelliott at hotmail dot com Reported By: rygorde4 at sbcglobal dot net Status: Open Bug Type: Unknown/Other Function Operating System: Not Applicable PHP Version: 5.2.0 New Comment: I currently get a issue with php 5.2 with ZenCart. I roll back to php 5.1.6 and it works fine... of course its all due to this php 5.2 bug... Im curently stuck in a hard place.. because.. Im a Web Hosting provider.. So either.. I run php 5.2 to get the security fixes and my customers are SOL that has issues with this bug.. Or.. run insecure code to keep my customers happy.. My question is.. any idea when this is going to be fixed? If I asked in the wrong place... please direct me to the correct place... as this is very important to me... Previous Comments: [2006-11-06 13:42:19] c dot boulton at mybboard dot com Maybe relates to this? http://bugs.php.net/bug.php?id=36759 [2006-11-05 15:34:34] linksys at yahoo dot com The same issue occurs in ZenCart v1.3.6 with PHP 5.2.0 regarding using class as global variable. Discussions are here: http://www.zen-cart.com/forum/showthread.php?t=50534 [2006-11-04 19:20:52] rygorde4 at sbcglobal dot net Description: If functions are called within __destruct without register_shutdown_function being called on __destruct within a class, and global variables (that are assigned classes) called in that class will not work. This is a bug specificly with PHP 5.2.0. This bug was reported multiple times at my discussion system (here http://community.mybboard.net/showthread.php?tid=13506 and here http://community.mybboard.net/showthread.php?tid=12430). Calling register_shutdown_function on __destruct, I was able to use that as a workaround, but the problem remains with __destruct. Please contact me with any information you need, and I will gladly assist you. Reproduce code: --- You can install a fresh version of MyBB 1.2 here: http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in inc/class_core.php Expected result: No error, shutdown functions should run properly Actual result: -- Fatal error: Call to a member function run_hooks() on a non-object in /www/xxx/pub/inc/functions.php on line 146 [2006-11-04 19:18:23] rygorde4 at sbcglobal dot net Description: If functions are called within __destruct without register_shutdown_function being called on __destruct within a class, and global variables that are classes will not work. This is a bug specificly with PHP 5.2.0. This bug was reported multiple times at my discussion system (here http://community.mybboard.net/showthread.php?tid=13506 and here http://community.mybboard.net/showthread.php?tid=12430). Calling register_shutdown_function on __destruct, I was able to use that as a workaround, but the problem remains with __destruct. Please contact me with any information you need, and I will gladly assist you. Reproduce code: --- You can install a fresh version of MyBB 1.2 here: http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in inc/class_core.php Expected result: No error, shutdown functions should run properly Actual result: -- Fatal error: Call to a member function run_hooks() on a non-object in /www/xxx/pub/inc/functions.php on line 146 -- Edit this bug report at http://bugs.php.net/?id=39381&edit=1
#39121 [Opn->Csd]: Incorrect return array handling in non-wsdl soap client.
ID: 39121 Updated by: [EMAIL PROTECTED] Reported By: sos at sokhapkin dot dyndns dot org -Status: Open +Status: Closed Bug Type: SOAP related Operating System: Gentoo linux PHP Version: 5.1.6 Assigned To: dmitry New Comment: The bug is fixed in CVS HEAD and PHP_5_2. Previous Comments: [2006-11-01 16:55:32] hpuiu at xentra dot ro Hi, I am using PHP 5.1.6 on Windows XP and I have also encountered this issue while trying to work with DIDX.org SOAP. There are functions that should return arrays, but instead, all I get is an array that contains the last record and not a multidimensional array as I expect. I have downloaded PHP 5.2-dev and the problem is still there. Puiu Hrenciuc [2006-10-23 15:07:46] sos at sokhapkin dot dyndns dot org I emailed the soap message, the bugtracker did not accept it. [2006-10-23 06:46:27] [EMAIL PROTECTED] I cannot analyze the report without full SOAP Envelope. I fixed one bug related to this report, but I cannot be sure that it fixes your issue. (Your pathch is completly wrong). [2006-10-10 22:42:36] [EMAIL PROTECTED] Assigned to the maintainer. [2006-10-10 22:32:38] sos at sokhapkin dot dyndns dot org Description: Return soap type array needs special handling in non-wsdl mode. The return array should have numeric indexes only because all elements of returned array have the same name. Here is the pacth to fix the problem: --- php_packet_soap.c.orig 2006-01-01 07:50:13.0 -0500 +++ php_packet_soap.c 2006-10-10 17:50:50.0 -0400 @@ -338,9 +338,18 @@ if (val != NULL) { if (!node_is_equal_ex(val,"result",RPC_SOAP12_NAMESPACE)) { zval *tmp; + int isarray = 0; + if(xmlHasProp(val, "type")) { + xmlChar *type; + type = xmlGetProp(val, "type"); + if(strstr(type, ":Array")) + isarray = 1; + xmlFree(type); + } + tmp = master_to_zval(NULL, val); - if (val->name) { + if (val->name && !isarray) { add_assoc_zval(return_value, (char*)val->name, tmp); } else { add_next_index_zval(return_value, tmp); Reproduce code: --- Here is an example of soap return xml: 1732608065011.9901732588259911.990 Expected result: Array => ( [0] => Array => ( [0] => 17326080650 [1] => 1 [2] => 1.99 [3] => 0 ) [1] => Array => ( [0] => 17325882599 [1] => 1 [2] => 1.99 [3] => 0 ) ) Actual result: -- Array => ( [Array] => Array => ( [0] => 17325882599 [1] => 1 [2] => 1.99 [3] => 0 ) ) -- Edit this bug report at http://bugs.php.net/?id=39121&edit=1
#39396 [Opn]: stream_set_blocking crashes
ID: 39396 User updated by: maurice at iceblog dot de Reported By: maurice at iceblog dot de Status: Open Bug Type: Streams related Operating System: Windows XP PHP Version: 5.2.0 New Comment: stream_socket_client should at least return FALSE or an error if you just use STREAM_CLIENT_ASYNC_CONNECT without STREAM_CLIENT_CONNECT. Previous Comments: [2006-11-06 10:33:33] maurice at iceblog dot de Description: When you use stream_socket_client with asynchronous connect (STREAM_CLIENT_ASYNC_CONNECT), but do not specify STREAM_CLIENT_CONNECT then stream_set_blocking will crash PHP on Windows XP. The documentation does NOT tell you to use STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT. I think STREAM_CLIENT_ASYNC_CONNECT should implicate STREAM_CLIENT_CONNECT. -- Possibility 1 to fix implication - #define STREAM_XPORT_CONNECT 2 #define STREAM_XPORT_CONNECT_ASYNC 18 // instead of 16 #define PHP_STREAM_CLIENT_CONNECT4 #define PHP_STREAM_CLIENT_ASYNC_CONNECT 6 // instead of 2 -- Possibility 2 to fix "implication" --- Patch for 5.2.0 source (not CVS). --- transports.c2006-01-01 13:50:18.0 +0100 +++ transports-maurice.c2006-11-06 11:18:49.0 +0100 @@ -136,7 +136,7 @@ if ((flags & STREAM_XPORT_SERVER) == 0) { /* client */ - if (flags & STREAM_XPORT_CONNECT) { + if (flags & STREAM_XPORT_CONNECT || flags & STREAM_XPORT_CONNECT_ASYNC) { if (-1 == php_stream_xport_connect(stream, name, namelen, flags & STREAM_XPORT_CONNECT_ASYNC ? 1 : 0, timeout, &error_text, error_code TSRMLS_CC)) { - There are other (somehow) related bugs: http://bugs.php.net/bug.php?id=30386 http://bugs.php.net/bug.php?id=28245 Reproduce code: --- \n"; } else { var_dump(stream_set_blocking($fp, false)); fclose($fp); } ?> Expected result: If you do not specify STREAM_CLIENT_CONNECT in stream_socket_client the socket never ever gets connected. Thus, stream_set_blocking should return FALSE and throw an E_WARNING. However, as this is a stream function and the stream is still considered "valid", TRUE might also be all right. Under Debian Linux (Sarge, Kernel 2.6.8) stream_set_blocking returns TRUE (which I think is misleading). Actual result: -- Crashes under Windows XP; returns TRUE on Linux. -- Edit this bug report at http://bugs.php.net/?id=39396&edit=1
#39400 [Opn]: More differences beetween functions and the mbstring versions
ID: 39400 User updated by: christoph at ziegenberg dot de Reported By: christoph at ziegenberg dot de Status: Open Bug Type: mbstring related Operating System: Win XP PHP Version: 5.2.0 New Comment: Point "different behaviour between a function and the case-insensitive version" isn't right, I meant the difference between stripos() and strripos() (which behave equal in the mbstring version). Previous Comments: [2006-11-06 13:21:54] christoph at ziegenberg dot de Description: I posted a bug for the wrong behaviour of mb_strstr() compared to strstr() before - this has been fixed, but also the other functions behave different. Here a code to see more differences: - different behaviours between functions and the mbstring versions, - different error messages and - different behaviour between a function and the case-insensitive version Reproduce code: --- '); stripos('', ',', 0); mb_stripos('', ',', 0); print('stripos (offest > length):'); stripos('1', ',', 3); mb_stripos('1', ',', 3); print('strripos (empty haystack):'); strripos('', ',', 0); mb_strripos('', ',', 0); print('strripos (offest > length):'); strripos('1', ',', 3); mb_strripos('1', ',', 3); print('stristr (empty haystack):'); stristr('', ','); mb_stristr('', ','); print('strrichr (empty haystack):'); strrchr('', ','); mb_strrchr('', ','); ?> Expected result: stripos (empty haystack): stripos (offest > length): [same error message, dunno which is the better one - they mean the same, but it would be better to get the same text. or no error as in strripos(), see below.] strripos (empty haystack): strripos (offest > length): [same as for stripos() - strripos() returns no error here] stristr (empty haystack): strrichr (empty haystack): Actual result: -- stripos (empty haystack): Warning: mb_stripos() [function.mb-stripos]: Empty haystack in W:\www\mb_functions.php on line 4 stripos (offest > length): Warning: stripos() [function.stripos]: Offset not contained in string. in W:\www\mb_functions.php on line 7 Warning: mb_stripos() [function.mb-stripos]: Offset is out of range in W:\www\mb_functions.php on line 8 strripos (empty haystack): Warning: mb_strripos() [function.mb-strripos]: Empty haystack in W:\www\mb_functions.php on line 13 strripos (offest > length): Warning: mb_strripos() [function.mb-strripos]: Offset is out of range in W:\www\mb_functions.php on line 17 stristr (empty haystack): Warning: mb_stristr() [function.mb-stristr]: Empty haystack in W:\www\mb_functions.php on line 21 strrichr (empty haystack): Warning: mb_strrchr() [function.mb-strrchr]: Empty haystack in W:\www\mb_functions.php on line 25 -- Edit this bug report at http://bugs.php.net/?id=39400&edit=1
#39346 [Opn]: Unsetting a static variable inside a destructor causes segfault later on
ID: 39346 User updated by: daan at parse dot nl Reported By: daan at parse dot nl Status: Open Bug Type: Reproducible crash Operating System: Slackware 10.2 PHP Version: 5.2.0RC5 New Comment: Also crashing on 5.2.0 final. Previous Comments: [2006-11-02 16:54:38] daan at parse dot nl Description: Tested on 5.2.0RC6 Unsetting a static variable referring to the object itself causes a segfault later on. (possible alloc problems) I was able to reproduce segfaults in this situation with other functions besides debug_backtrace(), for instance with mysqli_fetch_assoc(). The resulting backtrace also led to _zend_mm_alloc_int. (I am presuming it is the same bug) PS. The print_r() is not required to trigger the crash. Reproduce code: --- test(); $this->_id = $id; self::$instances[$this->_id] = $this; } function __destruct() { unset(self::$instances[$this->_id]); } function test() { print_r(debug_backtrace()); } } $test = new test(2); $test = new test(1); $test = new test(2); $test = new test(3); ?> Expected result: No crash. Actual result: -- #0 _zend_mm_alloc_int (heap=0x80ebbb8, size=16) at /usr/src/php-5.2.0RC6/Zend/zend_alloc.c:1090 #1 0x4063f953 in add_assoc_long_ex (arg=0x3, key=0x40769a60 "line", key_len=5, n=16) at /usr/src/php-5.2.0RC6/Zend/zend_API.c:977 #2 0x4064d2d8 in zend_fetch_debug_backtrace (return_value=0x40f289cc, skip_last=1, provide_object=1) at /usr/src/php-5.2.0RC6/Zend/zend_builtin_functions.c:1962 #3 0x40658d54 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffacc0) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:200 #4 0x40658489 in execute (op_array=0x40f282c8) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92 #5 0x40658709 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffae80) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:234 #6 0x40658489 in execute (op_array=0x40f28fd4) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92 #7 0x40658709 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffb0e0) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:234 #8 0x40658489 in execute (op_array=0x40f24194) at /usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92 #9 0x4063ebfc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.2.0RC6/Zend/zend.c:1097 #10 0x40604e2a in php_execute_script (primary_file=0xbfffd440) at /usr/src/php-5.2.0RC6/main/main.c:1758 #11 0x406bf882 in apache_php_module_main (r=0x80cb5bc, display_source_mode=0) at /usr/src/php-5.2.0RC6/sapi/apache/sapi_apache.c:53 #12 0x406c0296 in send_php (r=0x80cb5bc, display_source_mode=0, filename=0x0) at /usr/src/php-5.2.0RC6/sapi/apache/mod_php5.c:660 #13 0x406c04a6 in send_parsed_php (r=0x80cb5bc) at /usr/src/php-5.2.0RC6/sapi/apache/mod_php5.c:675 #14 0x08053ff7 in ap_invoke_handler () #15 0x08069039 in process_request_internal () #16 0x08069098 in ap_process_request () #17 0x080600ba in child_main () #18 0x08060262 in make_child () #19 0x080603c8 in startup_children () #20 0x08060a88 in standalone_main () #21 0x080612a6 in main () -- Edit this bug report at http://bugs.php.net/?id=39346&edit=1
#39384 [Opn]: PHP assumes that an object will not be used after serialize() is called on it
ID: 39384 User updated by: cw264701 at ohiou dot edu Reported By: cw264701 at ohiou dot edu Status: Open Bug Type: Class/Object related Operating System: Ubuntu Linux PHP Version: 5.2.0 New Comment: Yes, I understand that I need not set the "table" attribute to null. This was a bad example; sorry. My complaint isn't about a specific case of using serialize() and the magic __sleep() function. I am complaining that the whole concept is flawed. The PHP documentation is encouraging users to define this __sleep() function and, thus, modify their objects before they are serialized. This is kind of silly, because, when we serialize() an object, that exact object is not being serialized, *itself*, but a *serialized representation* of that object is being formed (and stored as a string). The intent of the __sleep() function is good: to allow some control over what is actually stored for a serialized version of an object. The problem is, it can have *side effects*. This really becomes a problem when you are working with a class that you didn't write. For example, I am using ezpdo. I carelessly (which should be okay in this case) serialize()'d one of my ezpdo-mapped objects before I was finished using it; things blew up. It shouldn't be "wrong" for me to do something like this: $_SESSION['purchase'] = serialize($myPurchaseObject); $smarty->assign('purchase', $myPurchaseObject); There, I attempt to store away my object in the session, just before I pass it off to my template engine for view rendering. Perhaps this technique would be considered bad practice (to a PHP guru/developer), but that shouldn't leave me in the dark with some broken code. When I use a class, I want to program to its *interface*, not an implementation; I shouldn't have to care whether or not it happens to define a __sleep() function, and therefore cannot be used after it has been passed to a call to serialize(). I understand the value of __sleep(), but I think the whole serialization library/interface needs re-thinking. I suggest one of three solutions: - When an object, O, is serialize()'d, PHP could create an exact copy of that object (a "shallow copy", I believe), let's say C. PHP would then call __sleep() for the new object, C, and serialize that instance of the class. This technique seems slightly risky, though, because we have to depend on the class' __sleep() function to not directly modify any of its referenced objects, but rather rely on those references to use their own __sleep() functions to do any cleaning up; the class shouldn't directly modify its references, but who knows... - Call an object's __wakeup() method after a serialized representation has been formed but before returning from the serialize() function. This method might be wasteful in many cases (where the object was never again used after serialization), but better safe than sorry. Perhaps the __wakeup() function could be called on the object only if an attempt is made to "use it" after the call to serialize(). - The quick-n-dirty solution would be to, simply, cough up an error message if an object is referenced *after* a call to serialize() has been made on it - *regardless of whether the object has an associated __sleep() method*. Previous Comments: [2006-11-06 12:27:29] s dot s at terra dot com dot br The object still running as expected. If you change the attribute table, its sure that when you read it again the value will be the last assigned; null in this case. Try to eliminate the line "$this->table = null;" and run the test again. You dont need to set the attribute to null to serialize the object as you are doing. The magic method __sleep is used to persist only the attributes you whant, not the entire object ;) >From the docs: - serialize() checks if your class has a function with the magic name __sleep. If so, that function is executed prior to any serialization. It **can** clean up the object and is supposed to return an array with the names of all variables of that object that **should** be serialized. [2006-11-04 20:59:46] cw264701 at ohiou dot edu Description: PHP assumes that I will not use an object after serializing it. This shouldn't cause problems if my object's class does not define a __sleep() function, but if it does, and that __sleep() function modifies the object, then I can't reliably use that object until it is recreated using unserialize(). There is no mention of this in the documentation for the serialize() function, or anywhere else that I saw. More importantly, if PHP expects me to *not* use an object after calling serialize() on it, then PHP should produce an error message if I *do* try to use that object before unserialization. This is one of several problems (not all necessaril
#39401 [NEW]: conflicting types for utf8_mime2text
From: wouter at widexs dot nl Operating system: Linux PHP version: 5.2.0 PHP Bug Type: IMAP related Bug description: conflicting types for utf8_mime2text Description: I get an error when trying to build PHP 5.2.0 with imap c-client 2006c1 (ftp://ftp.cac.washington.edu/mail/imap-2006c1.tar.Z) : /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' Which is correct, because: * PHP 5.2.0 : long utf8_mime2text(SIZEDTEXT *src, SIZEDTEXT *dst); * imap c-client 2006c1 : long utf8_mime2text (SIZEDTEXT *src,SIZEDTEXT *dst,long flags); Haven't tested with previous versions of PHP, but I assume the same will happen. IMAP c-client 2004g gives no problem. This could be seen as a DUP of #37948 and #38941, but it is still present in 5.2.0 ... Actual result: -- /bin/sh /opt/install/widexs_apache_2006_017/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/imap/ -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/ -DPHP_ATOM_INC -I/opt/install/widexs_apache_2006_017/php-5.2.0/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/main -I/opt/install/widexs_apache_2006_017/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/date/lib -I/usr/include/freetype2 -I/opt/install/widexs_apache_2006_017/imap-2006c1/c-client -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/oniguruma -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl -I/opt/install/widexs_apache_2006_017/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql -I/usr/local/pgsql/include -I/opt/install/widexs_apache_2006_017/php-5.2.0/TSRM -I/opt/install/widexs_apache_2006_017/php-5.2.0/Zend-I/usr/include -g -O2 -c /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c -o ext/imap/php_imap.lo /opt/install/widexs_apache_2006_017/php-5.2.0/ext/imap/php_imap.c:79: conflicting types for `utf8_mime2text' /opt/install/widexs_apache_2006_017/imap-2006c1/c-client/utf8.h:548: previous declaration of `utf8_mime2text' -- Edit bug report at http://bugs.php.net/?id=39401&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39401&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39401&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39401&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39401&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39401&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39401&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39401&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39401&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39401&r=support Expected behavior:http://bugs.php.net/fix.php?id=39401&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39401&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39401&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39401&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39401&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39401&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39401&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39401&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39401&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39401&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39401&r=mysqlcfg
#39392 [Opn->Bgs]: __toString back compatibility
ID: 39392 Updated by: [EMAIL PROTECTED] Reported By: marcos dot neves at gmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: ANY PHP Version: 5.2.0 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 See upgrade info Previous Comments: [2006-11-05 23:23:27] marcos dot neves at gmail dot com Description: Object that do not implement __toString, now stop the script with "PHP Catchable fatal error: Object of class {className} could not be converted to string in ..." But for backward compatibility, if __toString is not implemented, it should return the old object id value, or the name of class of the object for example. I agree that nobody can rely on old ObjectId string, but there´s thousand scripts that stringfy data for logging, like this: function log($vars) { foreach($vars as $var) echo $var; } function test($a, $b) { log(func_get_args()); } Reproduce code: --- class Foo { } echo new Foo; Expected result: Old behavior of conversion from object to string Actual result: -- Catchable fatal error: Object of class Foo could not be converted to string in ... -- Edit this bug report at http://bugs.php.net/?id=39392&edit=1
#39394 [Com]: Make failed with openssl compilation option
ID: 39394 Comment by: sysadmin at rollerscapes dot net Reported By: david dot bourgeois at gmail dot com Status: Open Bug Type: Compile Failure Operating System: Red Hat 7.2 PHP Version: 5.2.0 New Comment: Update OpenSSL, its noted in the Manuel you always must use the latest version! Previous Comments: [2006-11-06 08:32:57] david dot bourgeois at gmail dot com Description: Hi, I have a pb with compil of php 5.2.0 (previous versions of PHP5 work fine with the same compilation options). When I compile php 5.2.0 without openssl option, there is no problem. openssl version : 0.9.6m Compilation of PHP as a module with Apache 2.2.3 Reproduce code: --- You can see the configure options here : http://www.dlnet-inter.fr/compil-failed.txt Actual result: -- ext/openssl/.libs/openssl.o: In function `php_openssl_generate_private_key': /home/src/php-5.2.0/ext/openssl/openssl.c:2063: undefined reference to `DSA_get_default_method' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Erreur 1 -- Edit this bug report at http://bugs.php.net/?id=39394&edit=1
#39376 [Opn->Csd]: Unable to load Chinese characters from oci8
ID: 39376 User updated by: automap at gmail dot com Reported By: automap at gmail dot com -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: WindowsXP PHP Version: 5.2.0 New Comment: problem resolved! oci_connect() function should take the fourth parameter, which indicates the characterset, for example: oci_connect( $username, $password ,$db, 'ZHS16GBK'); Thanks to all Previous Comments: [2006-11-06 08:09:06] automap at gmail dot com Thanks to [EMAIL PROTECTED] the problem "Unable to load dynamic library " was resolved. but a new one occured: when I fetch data from remote oracle db, I get the Chinese data in '?', while the Eglish and numeric characterset is still ok. I have thought that it's due to the parameter 'xLNS_LANG',but I have changed many possible configure to the xLNS_LANG or NLS_LANG , NO effect. Why? [2006-11-05 15:28:12] jhtpeter at gmail dot com I get the same problem. My environment is: Windows 2003, Oracle9i Server, PHP 5.2 I installed oracle instant client and set these env variables: PATH=C:\instantclient;... TNS_ADMIN=C:\instantclient LD_LIBRARY_PATH=C:\instantclient and also edit registry as BUG#39096 instructions: rename NLS_LANG TO xLNS_LANG At last, apache logs report: unable to load php_oci8.dll It seem to if Oracle Server installed, PHP cannot use instant client as the same machine? [2006-11-04 18:42:36] crescentfreshpot at yahoo dot com You need oracle instant client installed. See bug #39360 [2006-11-04 12:09:06] automap at gmail dot com Description: after I upgraded the Apache from 2.0.59 to 2.2.3 then I downloaded php5.2.0 to replace the original php5.0.5 but when I start apache, error log shows as below: Unable to load dynamic library 'C:/php52/ext/php_oci8.dll' - \xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xb3\xcc\xd0\xf2\xa1\xa3\r\n in Unknown on line 0 Reproduce code: --- the error log shows that the php_oci8.dll is not loaded when Apache is started my oracle client version is 9.2.0.1 it's good to load oci8 dll before I upgrade because I upgrded php and apache , so I'm not sure whether it's a problem of php, either inside apache Expected result: I need to load oci8 into the apache ,so I can connect my oracle db Actual result: -- now the oci8 dll can't be loaded.is it the problem of php5.2.0? -- Edit this bug report at http://bugs.php.net/?id=39376&edit=1
#39381 [Com]: __destruct bug
ID: 39381 Comment by: c dot boulton at mybboard dot com Reported By: rygorde4 at sbcglobal dot net Status: Open Bug Type: Unknown/Other Function Operating System: Not Applicable PHP Version: 5.2.0 New Comment: Maybe relates to this? http://bugs.php.net/bug.php?id=36759 Previous Comments: [2006-11-05 15:34:34] linksys at yahoo dot com The same issue occurs in ZenCart v1.3.6 with PHP 5.2.0 regarding using class as global variable. Discussions are here: http://www.zen-cart.com/forum/showthread.php?t=50534 [2006-11-04 19:20:52] rygorde4 at sbcglobal dot net Description: If functions are called within __destruct without register_shutdown_function being called on __destruct within a class, and global variables (that are assigned classes) called in that class will not work. This is a bug specificly with PHP 5.2.0. This bug was reported multiple times at my discussion system (here http://community.mybboard.net/showthread.php?tid=13506 and here http://community.mybboard.net/showthread.php?tid=12430). Calling register_shutdown_function on __destruct, I was able to use that as a workaround, but the problem remains with __destruct. Please contact me with any information you need, and I will gladly assist you. Reproduce code: --- You can install a fresh version of MyBB 1.2 here: http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in inc/class_core.php Expected result: No error, shutdown functions should run properly Actual result: -- Fatal error: Call to a member function run_hooks() on a non-object in /www/xxx/pub/inc/functions.php on line 146 [2006-11-04 19:18:23] rygorde4 at sbcglobal dot net Description: If functions are called within __destruct without register_shutdown_function being called on __destruct within a class, and global variables that are classes will not work. This is a bug specificly with PHP 5.2.0. This bug was reported multiple times at my discussion system (here http://community.mybboard.net/showthread.php?tid=13506 and here http://community.mybboard.net/showthread.php?tid=12430). Calling register_shutdown_function on __destruct, I was able to use that as a workaround, but the problem remains with __destruct. Please contact me with any information you need, and I will gladly assist you. Reproduce code: --- You can install a fresh version of MyBB 1.2 here: http://mybboard.com/downloads.php using PHP 5.2.0. The problems lay in inc/class_core.php Expected result: No error, shutdown functions should run properly Actual result: -- Fatal error: Call to a member function run_hooks() on a non-object in /www/xxx/pub/inc/functions.php on line 146 -- Edit this bug report at http://bugs.php.net/?id=39381&edit=1
#39400 [NEW]: More differences beetween functions and the mbstring versions
From: christoph at ziegenberg dot de Operating system: Win XP PHP version: 5.2.0 PHP Bug Type: mbstring related Bug description: More differences beetween functions and the mbstring versions Description: I posted a bug for the wrong behaviour of mb_strstr() compared to strstr() before - this has been fixed, but also the other functions behave different. Here a code to see more differences: - different behaviours between functions and the mbstring versions, - different error messages and - different behaviour between a function and the case-insensitive version Reproduce code: --- '); stripos('', ',', 0); mb_stripos('', ',', 0); print('stripos (offest > length):'); stripos('1', ',', 3); mb_stripos('1', ',', 3); print('strripos (empty haystack):'); strripos('', ',', 0); mb_strripos('', ',', 0); print('strripos (offest > length):'); strripos('1', ',', 3); mb_strripos('1', ',', 3); print('stristr (empty haystack):'); stristr('', ','); mb_stristr('', ','); print('strrichr (empty haystack):'); strrchr('', ','); mb_strrchr('', ','); ?> Expected result: stripos (empty haystack): stripos (offest > length): [same error message, dunno which is the better one - they mean the same, but it would be better to get the same text. or no error as in strripos(), see below.] strripos (empty haystack): strripos (offest > length): [same as for stripos() - strripos() returns no error here] stristr (empty haystack): strrichr (empty haystack): Actual result: -- stripos (empty haystack): Warning: mb_stripos() [function.mb-stripos]: Empty haystack in W:\www\mb_functions.php on line 4 stripos (offest > length): Warning: stripos() [function.stripos]: Offset not contained in string. in W:\www\mb_functions.php on line 7 Warning: mb_stripos() [function.mb-stripos]: Offset is out of range in W:\www\mb_functions.php on line 8 strripos (empty haystack): Warning: mb_strripos() [function.mb-strripos]: Empty haystack in W:\www\mb_functions.php on line 13 strripos (offest > length): Warning: mb_strripos() [function.mb-strripos]: Offset is out of range in W:\www\mb_functions.php on line 17 stristr (empty haystack): Warning: mb_stristr() [function.mb-stristr]: Empty haystack in W:\www\mb_functions.php on line 21 strrichr (empty haystack): Warning: mb_strrchr() [function.mb-strrchr]: Empty haystack in W:\www\mb_functions.php on line 25 -- Edit bug report at http://bugs.php.net/?id=39400&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39400&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39400&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39400&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39400&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39400&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39400&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39400&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39400&r=support Expected behavior:http://bugs.php.net/fix.php?id=39400&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39400&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39400&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39400&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39400&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39400&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39400&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39400&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39400&r=mysqlcfg
#39384 [Com]: PHP assumes that an object will not be used after serialize() is called on it
ID: 39384 Comment by: s dot s at terra dot com dot br Reported By: cw264701 at ohiou dot edu Status: Open Bug Type: Class/Object related Operating System: Ubuntu Linux PHP Version: 5.2.0 New Comment: The object still running as expected. If you change the attribute table, its sure that when you read it again the value will be the last assigned; null in this case. Try to eliminate the line "$this->table = null;" and run the test again. You dont need to set the attribute to null to serialize the object as you are doing. The magic method __sleep is used to persist only the attributes you whant, not the entire object ;) >From the docs: - serialize() checks if your class has a function with the magic name __sleep. If so, that function is executed prior to any serialization. It **can** clean up the object and is supposed to return an array with the names of all variables of that object that **should** be serialized. Previous Comments: [2006-11-04 20:59:46] cw264701 at ohiou dot edu Description: PHP assumes that I will not use an object after serializing it. This shouldn't cause problems if my object's class does not define a __sleep() function, but if it does, and that __sleep() function modifies the object, then I can't reliably use that object until it is recreated using unserialize(). There is no mention of this in the documentation for the serialize() function, or anywhere else that I saw. More importantly, if PHP expects me to *not* use an object after calling serialize() on it, then PHP should produce an error message if I *do* try to use that object before unserialization. This is one of several problems (not all necessarily "bugs", but shaky designs), that I've come across recently, which greatly reduces the ability for PHP applications to take advantage of *transparency*. I.e., I should not have to care how a class is implemented (for instance, whether or not it uses the magic __sleep() function) to make use of it. I recently adopted the ezpdo (http://ezpdo.net/) ORM tool. It has probably hurt my productivity more than it has helped because it makes use of such leaky abstractions. Some of these may be the fault of that tool, but many flaws like this seem to be more general PHP problems. (Sorry for the rant, but I think issues like this are pretty important, and the reason I very often become frustrated with PHP.) Reproduce code: --- size = $size; for( $a = 1; $a <= $size; ++$a ) { for( $b = 1; $b <= $size; ++$b ) { $this->table[$a][$b] = $a * $b; } } } public function __sleep() { $this->table = null; return( array("size") ); } public function __wakeup() { $this->MultiplicationTable($this->size); } } $mt = new MultiplicationTable(4); echo $mt->size . ", " . $mt->table[4][4] . "\n"; $serialized_mt = serialize($mt); echo $mt->size . ", " . $mt->table[4][4] . "\n"; $unserialized_mt = unserialize($serialized_mt); echo $unserialized_mt->size . ", " . $unserialized_mt->table[4][4] . "\n"; ?> Expected result: Well, ideally the object would still "work" after creating a serialize()'d version of it, but I think making that work would require significant changes to PHP's whole serialization model (or perhaps you could just have __wakeup() be called right after serialization; perhaps only if the object is accessed again). But, the more realistic solution would probably result in some kind of error message when I try to access my $mt object after calling serialize() on it. Actual result: -- 4, 16 4, 4, 16 -- Edit this bug report at http://bugs.php.net/?id=39384&edit=1
#39398 [Opn]: No cast of logic type and silence
ID: 39398 User updated by: develar at gmail dot com Reported By: develar at gmail dot com Status: Open Bug Type: PDO related Operating System: Debian 3 PHP Version: 5.2.0 New Comment: var_dump($Db->query('SELECT * FROM test')->fetchAll()); Previous Comments: [2006-11-06 11:56:04] develar at gmail dot com Description: PDO does not cast a variable with boolean type in bindValue, does not do execute and is silent. I should cast manually - (int). Reproduce code: --- CREATE TABLE `test` ( `test` tinyint(1) NOT NULL default '0' ) ENGINE=MyISAM DEFAULT CHARSET=utf8; $Db = new PDO('mysql:host=localhost;dbname=test', 'root', ''); $Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC); $boolean = 1; $Pdo = $Db->prepare('INSERT INTO test VALUES (:boolean)'); $Pdo->bindValue(':boolean', isset($boolean), PDO::PARAM_INT); $Pdo->execute(); Expected result: array(1) { [0]=> array(1) { ["test"]=> string(1) "1" } } Actual result: -- array(0) { } -- Edit this bug report at http://bugs.php.net/?id=39398&edit=1
#39398 [NEW]: No cast of logic type and silence
From: develar at gmail dot com Operating system: Debian 3 PHP version: 5.2.0 PHP Bug Type: PDO related Bug description: No cast of logic type and silence Description: PDO does not cast a variable with boolean type in bindValue, does not do execute and is silent. I should cast manually - (int). Reproduce code: --- CREATE TABLE `test` ( `test` tinyint(1) NOT NULL default '0' ) ENGINE=MyISAM DEFAULT CHARSET=utf8; $Db = new PDO('mysql:host=localhost;dbname=test', 'root', ''); $Db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $Db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC); $boolean = 1; $Pdo = $Db->prepare('INSERT INTO test VALUES (:boolean)'); $Pdo->bindValue(':boolean', isset($boolean), PDO::PARAM_INT); $Pdo->execute(); Expected result: array(1) { [0]=> array(1) { ["test"]=> string(1) "1" } } Actual result: -- array(0) { } -- Edit bug report at http://bugs.php.net/?id=39398&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39398&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39398&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39398&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39398&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39398&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39398&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39398&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39398&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39398&r=support Expected behavior:http://bugs.php.net/fix.php?id=39398&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39398&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39398&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39398&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39398&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39398&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39398&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39398&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39398&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39398&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39398&r=mysqlcfg
#39397 [NEW]: invalid statement handle in Unknown on line 0
From: sailormax at inbox dot lv Operating system: Win32 / Linux PHP version: 5.2.0 PHP Bug Type: InterBase related Bug description: invalid statement handle in Unknown on line 0 Description: PHP output warning: Warning: Unknown: invalid statement handle in Unknown on line 0 if don't use "connection_id" as parameter for function ibase_close() Firebird 2.0 Release Candidate Reproduce code: --- "; } ibase_close(); ?> Expected result: output list of data in table Actual result: -- output list of data in table and Warning: Unknown: invalid statement handle in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=39397&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39397&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39397&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39397&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39397&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39397&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39397&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39397&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39397&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39397&r=support Expected behavior:http://bugs.php.net/fix.php?id=39397&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39397&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39397&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39397&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39397&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39397&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39397&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39397&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39397&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39397&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39397&r=mysqlcfg
#39396 [NEW]: stream_set_blocking crashes
From: maurice at iceblog dot de Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Streams related Bug description: stream_set_blocking crashes Description: When you use stream_socket_client with asynchronous connect (STREAM_CLIENT_ASYNC_CONNECT), but do not specify STREAM_CLIENT_CONNECT then stream_set_blocking will crash PHP on Windows XP. The documentation does NOT tell you to use STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT. I think STREAM_CLIENT_ASYNC_CONNECT should implicate STREAM_CLIENT_CONNECT. -- Possibility 1 to fix implication - #define STREAM_XPORT_CONNECT 2 #define STREAM_XPORT_CONNECT_ASYNC 18 // instead of 16 #define PHP_STREAM_CLIENT_CONNECT4 #define PHP_STREAM_CLIENT_ASYNC_CONNECT 6 // instead of 2 -- Possibility 2 to fix "implication" --- Patch for 5.2.0 source (not CVS). --- transports.c2006-01-01 13:50:18.0 +0100 +++ transports-maurice.c2006-11-06 11:18:49.0 +0100 @@ -136,7 +136,7 @@ if ((flags & STREAM_XPORT_SERVER) == 0) { /* client */ - if (flags & STREAM_XPORT_CONNECT) { + if (flags & STREAM_XPORT_CONNECT || flags & STREAM_XPORT_CONNECT_ASYNC) { if (-1 == php_stream_xport_connect(stream, name, namelen, flags & STREAM_XPORT_CONNECT_ASYNC ? 1 : 0, timeout, &error_text, error_code TSRMLS_CC)) { - There are other (somehow) related bugs: http://bugs.php.net/bug.php?id=30386 http://bugs.php.net/bug.php?id=28245 Reproduce code: --- \n"; } else { var_dump(stream_set_blocking($fp, false)); fclose($fp); } ?> Expected result: If you do not specify STREAM_CLIENT_CONNECT in stream_socket_client the socket never ever gets connected. Thus, stream_set_blocking should return FALSE and throw an E_WARNING. However, as this is a stream function and the stream is still considered "valid", TRUE might also be all right. Under Debian Linux (Sarge, Kernel 2.6.8) stream_set_blocking returns TRUE (which I think is misleading). Actual result: -- Crashes under Windows XP; returns TRUE on Linux. -- Edit bug report at http://bugs.php.net/?id=39396&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39396&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39396&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39396&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39396&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39396&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39396&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39396&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39396&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39396&r=support Expected behavior:http://bugs.php.net/fix.php?id=39396&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39396&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39396&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39396&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39396&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39396&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39396&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39396&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39396&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39396&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39396&r=mysqlcfg
#37236 [Csd->Opn]: move_uploaded_file() does not work when "upload_tmp_dir" is other fs than dest
ID: 37236 User updated by: youza at post dot cz Reported By: youza at post dot cz -Status: Closed +Status: Open Bug Type: *Directory/Filesystem functions Operating System: fedora core 4 PHP Version: 5.1.4, 4.4.2 New Comment: Hello, please i cannot find the fix in 4.4.4 CVS, please help me. Is this bug fixed in the 4.4.4(5) CVS ? Sorry if my question is irrelevant. Previous Comments: [2006-10-23 07:49:30] youza at post dot cz Sorry, I cannot find this fix in CVS for 4.4.4 ? [2006-10-23 07:46:41] youza at post dot cz I can find this fix in CVS for 4.4.4 ? [2006-10-16 15:12:27] [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. [2006-08-04 07:36:42] youza at post dot cz Other details: if upload_tmp_dir is on a different filesystem then the destination file, the function move_uploaded_file (for PHP 4.4.2) - work fine and the destination file has permission -rw-rw-r-- UID/GID apache/apache ( apache process started witch umask 0002 ). But upload_tmp_dir is on a the same filesystem then the destination file, permission for new destination file is -rw--- UID/GID apache/apache ( tested PHP 4.4.2, PHP 5.1.4 ) The permissions is incorrect users in apache group will not have access to this files. Diferent permission depending to the upload_tmp_dir and filesystem location not correct. [2006-07-23 12:27:59] [EMAIL PROTECTED] Sara, anything new about this? 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/37236 -- Edit this bug report at http://bugs.php.net/?id=37236&edit=1
#39389 [WFx]: of course it would be helpfull
ID: 39389 User updated by: corinl at gmx dot de -Summary: make some errors catchable Reported By: corinl at gmx dot de Status: Wont fix Bug Type: Feature/Change Request Operating System: linux debian PHP Version: 5.2.0 New Comment: well, assume you change the name of an methode. in a big project, it takes hours / days to make sure, all affected places have been adjusted. to find the missing ones you have either to get the "white page" (error page) yourself, a customer has to provide the info or you would have to look for "fatal error..." in the error logs of php. having this catchable, i could make php send me a nice email with backtrace when such an error occurs... :) also when dealing with higly dynamic objects it could be very usefull to find logic/programming errors, which only occur in a special context. without a backtrace (with the internal php fatal error unluckily does not output), it's very hard to debug such errors. Previous Comments: [2006-11-06 08:34:05] [EMAIL PROTECTED] Actually, they do... and why would you want to catch that in the first place? It's a coding error which you catch while testing your code. [2006-11-05 16:59:00] corinl at gmx dot de Description: i assume php errors like -- Fatal error: Call to a member function ... on a non-object Fatal error: Call to undefined method ... -- don't leave php in an instable state. these errors should also be catchable by a custom error handler using E_RECOVERABLE_ERROR as it help's a lot with debugging. -- Edit this bug report at http://bugs.php.net/?id=39389&edit=1
#39393 [Opn->Bgs]: Problem with mail function
ID: 39393 Updated by: [EMAIL PROTECTED] Reported By: kiranbhimanwar at gmail dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: LINUX PHP Version: 4.4.4 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: [2006-11-06 05:24:54] kiranbhimanwar at gmail dot com Description: How to add multiple mail id's in BCC header Is there any limit that what no of mail ids I can add in BCC header. Please Help -Kiran -- Edit this bug report at http://bugs.php.net/?id=39393&edit=1
#39389 [Opn->WFx]: make some errors catchable
ID: 39389 Updated by: [EMAIL PROTECTED] Reported By: corinl at gmx dot de -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: linux debian PHP Version: 5.2.0 New Comment: Actually, they do... and why would you want to catch that in the first place? It's a coding error which you catch while testing your code. Previous Comments: [2006-11-05 16:59:00] corinl at gmx dot de Description: i assume php errors like -- Fatal error: Call to a member function ... on a non-object Fatal error: Call to undefined method ... -- don't leave php in an instable state. these errors should also be catchable by a custom error handler using E_RECOVERABLE_ERROR as it help's a lot with debugging. -- Edit this bug report at http://bugs.php.net/?id=39389&edit=1
#39394 [NEW]: Make failed with openssl compilation option
From: david dot bourgeois at gmail dot com Operating system: Red Hat 7.2 PHP version: 5.2.0 PHP Bug Type: Compile Failure Bug description: Make failed with openssl compilation option Description: Hi, I have a pb with compil of php 5.2.0 (previous versions of PHP5 work fine with the same compilation options). When I compile php 5.2.0 without openssl option, there is no problem. openssl version : 0.9.6m Compilation of PHP as a module with Apache 2.2.3 Reproduce code: --- You can see the configure options here : http://www.dlnet-inter.fr/compil-failed.txt Actual result: -- ext/openssl/.libs/openssl.o: In function `php_openssl_generate_private_key': /home/src/php-5.2.0/ext/openssl/openssl.c:2063: undefined reference to `DSA_get_default_method' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Erreur 1 -- Edit bug report at http://bugs.php.net/?id=39394&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39394&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39394&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39394&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39394&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39394&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39394&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39394&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39394&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39394&r=support Expected behavior:http://bugs.php.net/fix.php?id=39394&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39394&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39394&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39394&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39394&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39394&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39394&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39394&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39394&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39394&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39394&r=mysqlcfg
#39376 [Opn]: Unable to load Chinese characters from oci8
ID: 39376 User updated by: automap at gmail dot com -Summary: Unable to load dynamic library 'ext/php_oci8.dll' Reported By: automap at gmail dot com Status: Open Bug Type: OCI8 related Operating System: WindowsXP PHP Version: 5.2.0 New Comment: Thanks to [EMAIL PROTECTED] the problem "Unable to load dynamic library " was resolved. but a new one occured: when I fetch data from remote oracle db, I get the Chinese data in '?', while the Eglish and numeric characterset is still ok. I have thought that it's due to the parameter 'xLNS_LANG',but I have changed many possible configure to the xLNS_LANG or NLS_LANG , NO effect. Why? Previous Comments: [2006-11-05 15:28:12] jhtpeter at gmail dot com I get the same problem. My environment is: Windows 2003, Oracle9i Server, PHP 5.2 I installed oracle instant client and set these env variables: PATH=C:\instantclient;... TNS_ADMIN=C:\instantclient LD_LIBRARY_PATH=C:\instantclient and also edit registry as BUG#39096 instructions: rename NLS_LANG TO xLNS_LANG At last, apache logs report: unable to load php_oci8.dll It seem to if Oracle Server installed, PHP cannot use instant client as the same machine? [2006-11-04 18:42:36] crescentfreshpot at yahoo dot com You need oracle instant client installed. See bug #39360 [2006-11-04 12:09:06] automap at gmail dot com Description: after I upgraded the Apache from 2.0.59 to 2.2.3 then I downloaded php5.2.0 to replace the original php5.0.5 but when I start apache, error log shows as below: Unable to load dynamic library 'C:/php52/ext/php_oci8.dll' - \xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xb3\xcc\xd0\xf2\xa1\xa3\r\n in Unknown on line 0 Reproduce code: --- the error log shows that the php_oci8.dll is not loaded when Apache is started my oracle client version is 9.2.0.1 it's good to load oci8 dll before I upgrade because I upgrded php and apache , so I'm not sure whether it's a problem of php, either inside apache Expected result: I need to load oci8 into the apache ,so I can connect my oracle db Actual result: -- now the oci8 dll can't be loaded.is it the problem of php5.2.0? -- Edit this bug report at http://bugs.php.net/?id=39376&edit=1