#24424 [Com]: Complains about libxml even when not compiling with XML
ID: 24424 Comment by: faern at sbcglobal dot net Reported By: liz at xcalibur dot demon dot co dot uk Status: Bogus Bug Type: PHP options/info functions Operating System: linux 2.4.20 PHP Version: 5.0.0b1 (beta1) New Comment: Nope, still broken. checking for simplexml support... yes configure: error: libxml2 version 2.5.1 or greater required. This is after urpmi the version I had. This stinks, I don't want to break a ton of dependencies over a feature I don't even want. You need to add --leave-xml-the-hell-alone :( Previous Comments: [2003-08-20 01:48:29] schweitzerh at hotmail dot comm I was having the same issue this guy was experiencing, but I actually was recompiling PHP specifically for XML support. Installing libxml2-devel did the trick! Thanks! [2003-07-01 01:11:59] [EMAIL PROTECTED] --enable-wddx requires libxml2 too [2003-07-01 01:06:24] liz at xcalibur dot demon dot co dot uk Given I have submitted my entire configuration, please, tell me what. The line now reads ./configure --with-mysql=/usr/bin --with-apache=/usr/src/web/apache_1.3.27 --enable-discard-path --enable-track-vars --disable-debug --enable-dbase --enable-trans-sid --enable-inline-optimization --enable-ftp --enable-sockets --with-imap --with-imap-ssl=/usr/include/openssl --enable-libgcc --disable-ipv6 --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-zlib -dir=/usr/local/lib --enable-dio --enable-gd-native-ttf --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx --enable-yp --disable-xml --disable-simplexml --disable-dom [2003-06-30 17:55:58] [EMAIL PROTECTED] It works just fine. You're just doing something wrong. [2003-06-30 17:05:17] [EMAIL PROTECTED] --disable-xml --disable-simplexml --disable-dom --without-pear does it with latest CVS. 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/24424 -- Edit this bug report at http://bugs.php.net/?id=24424&edit=1
#25798 [Fbk->Ver]: forever-running or no-error-abort in preg_match
ID: 25798 Updated by: [EMAIL PROTECTED] Reported By: musha dot yoshinori at nifty dot ne dot jp -Status: Feedback +Status: Verified Bug Type: PCRE related Operating System: Windows XP Pro -PHP Version: 4.3.3 +PHP Version: 4.3.4RC2-dev New Comment: Reproduced with latest CVS (under Windows XP), PHP as Apache2 module. Works fine with CLI. Previous Comments: [2003-10-15 01:51:59] [EMAIL PROTECTED] No, it's not okay, most likely you're mixing two different set of dlls from different PHP versions. Make sure you don't have ANY php4ts.dll files in your system except for the one that comes with the snapshot. [2003-10-14 22:45:30] musha dot yoshinori at nifty dot ne dot jp I am sorry for late. I was busy for business. Now, I checked the bug using the latest version of PHP, PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. By the bug, I feel that it is difficult to describe regular expressions avoiding the bug in preg_match. I want to describe regular expressions more freely. By the way, in the latest version, phpinfo() shows "Apache Version: Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows "4.3.3". Is it OK? Thank you. [2003-10-10 11:50:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp I know that it depends on platforms. I use PHP on Windows XP Pro, Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match with the same regular expression works fine on other platform. Thank you. [2003-10-08 22:36:43] [EMAIL PROTECTED] Works fine here on Linux, what locale are you using? 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/25798 -- Edit this bug report at http://bugs.php.net/?id=25798&edit=1
#25798 [Opn->Fbk]: forever-running or no-error-abort in preg_match
ID: 25798 Updated by: [EMAIL PROTECTED] Reported By: musha dot yoshinori at nifty dot ne dot jp -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.3.3 New Comment: No, it's not okay, most likely you're mixing two different set of dlls from different PHP versions. Make sure you don't have ANY php4ts.dll files in your system except for the one that comes with the snapshot. Previous Comments: [2003-10-14 22:45:30] musha dot yoshinori at nifty dot ne dot jp I am sorry for late. I was busy for business. Now, I checked the bug using the latest version of PHP, PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. By the bug, I feel that it is difficult to describe regular expressions avoiding the bug in preg_match. I want to describe regular expressions more freely. By the way, in the latest version, phpinfo() shows "Apache Version: Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows "4.3.3". Is it OK? Thank you. [2003-10-14 20:31:51] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-10 11:50:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp I know that it depends on platforms. I use PHP on Windows XP Pro, Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match with the same regular expression works fine on other platform. Thank you. [2003-10-08 22:36:43] [EMAIL PROTECTED] Works fine here on Linux, what locale are you using? 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/25798 -- Edit this bug report at http://bugs.php.net/?id=25798&edit=1
#25838 [Bgs]: Dom_Node->child_nodes() is not live as the W3C DOM specification demands
ID: 25838 Updated by: [EMAIL PROTECTED] Reported By: Martin dot Honnen at arcor dot de Status: Bogus Bug Type: DOM XML related Operating System: Windows XP PHP Version: 4.3.3 New Comment: Just for your Information: Once we have implemented NodeLists in the new ext/dom for PHP5, this should work as expected by the W3C. Previous Comments: [2003-10-13 05:29:14] Martin dot Honnen at arcor dot de But the DOM specification says "changes are automatically reflected in the NodeList, without further action on the user's part". If you have to call child_nodes() again and again to have it updated then changes are not automatically reflected in the NodeList. Compare a simple JavaScript program to be run in Mozilla: var xmlDocument = document.implementation.createDocument('', '', null); var rootElement = xmlDocument.createElement('gods'); xmlDocument.appendChild(rootElement); var childNodes = rootElement.childNodes; for (var i = 0; i < 5; i++) { var god = xmlDocument.createElement('god'); god.setAttribute('name', 'god ' + i); rootElement.appendChild(god); alert(childNodes.length); } You will find that childNodes.length is incremented although childNodes is created outside of the loop. [2003-10-12 22:15:27] [EMAIL PROTECTED] It works fine when you actually set the $childNodes variable inside the for() loop. [2003-10-11 12:23:04] Martin dot Honnen at arcor dot de Description: The W3C DOM Level 2 specification at http://www.w3.org/TR/DOM-Level-2-Core/core.html#td-live says about NodeList collections that they should be live, meaning if a DOM user gets a NodeList object containing the children of an Element, then subsequently adds more children to that element (or removes children, or modifies them), those changes are automatically reflected in the NodeList, without further action on the user's part. However my test with PHP 4.3.3 and the following settings for DOMXML DOM/XML enabled DOM/XML API Version 20020815 libxml Version 20507 HTML Supportenabled XPath Support enabled XPointer Supportenabled DOM/XSLTenabled libxslt Version 1.0.30 libxslt compiled against libxml Version 2.5.7 shows that the result returned from Node->child_nodes() is not live but static. Reproduce code: --- \n"; echo htmlentities($xmlDocument->dump_mem(true)); echo "\n"; } $xmlDocument = domxml_new_doc("1.0"); $rootElement = $xmlDocument->create_element("gods"); $xmlDocument->append_child($rootElement); $childNodes = $rootElement->child_nodes(); echo 'count($childNodes): ' . count($childNodes) . "\n"; $xmlDocument->append_child($rootElement); for ($i = 0; $i < 5; $i++) { $god = $xmlDocument->create_element("god"); $god->set_attribute("name", "god $i"); $rootElement->append_child($god); dumpDoc($xmlDocument); echo 'count($childNodes): ' . count($childNodes) . "\n"; } ?> Expected result: I would expect count($childNodes) to be incremented every time $rootElement->append_child($god) is called. That is what the W3C DOM understands to be a live collection, and that is what happens with conformant DOM implementations (as the one in Mozilla or the one in SUN's Java SDK 1.4). Actual result: -- The output with dump_mem shows that child elements are added but the output of count($childNodes) is always 0. -- Edit this bug report at http://bugs.php.net/?id=25838&edit=1
#25777 [Opn->Csd]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds
ID: 25777 Updated by: [EMAIL PROTECTED] Reported By: duh at dowebwedo dot com -Status: Open +Status: Closed Bug Type: MSSQL related Operating System: Debian GNU/Linux 3.0 PHP Version: 4.3.4RC1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-10-10 06:12:57] duh at dowebwedo dot com the configure line is: './configure' '--with-mysql' '--with-apxs=/www/bin/apxs' '--with-gd=/usr/local' '--with-png-dir' '--with-freetype-dir' '--with-pear' '--with-zlib-dir' '--enable-track-vars' '--enable-trans-sid' '--disable-posix-threads' '--enable-shared' '--with-pgsql=/usr' '--with-unixODBC=/usr/local/easysoft/unixODBC' '--with-mssql=/usr/local' [2003-10-07 19:09:27] [EMAIL PROTECTED] What was the configure line used to configure PHP? [2003-10-07 09:43:10] duh at dowebwedo dot com Description: I am busy developing a new improved version of our intranet running on Apache/php/Debian and moved in this version from ODBC to MSSQL/Sybase connections (ODBC gave a lot of overhead and appeared being quite slow). In several intranet functions we aquire data from the Exact financial suite (http://www.exactsoftware.com) which is largely used in The Netherlands and abroad and which currently uses MSSQL as a database backend. In the most recent versions of exact you can still see their MS-DOS history (exact used btrieve and several other MS-DOS databases in the old days) because several columns are still padded to the maximum column width. Hence the word "hi" in a varchar(8) would be stored as "hi " (hi+6 spaces). Now when using mssql_* functions in php over freetds all selected values are right trimmed, so SELECT hi FROM table will return "hi" instead of the actual data in the table "hi ". I have currently only tried selecting, i don't know what happens when inserting (probably the same?). Obviously, this is not what I want since this would lead to data inconsistency (in your financial system!) and an unuseable financial system (which ofcourse is the worst that could happen to a company). At first I thought it was due to the fact that sybase used to right trim these values so freetds does it as well for compatibility's sake. But when I executed a query command line through the tsql (/usr/local/bin/tsql) application it appeared that then the values were NOT being right trimmed. So appearantly the interface between freetds and my application (which in my opinion can only be php) does the trimming of values with spaces. Ofcourse one could say that I need to trim or append spaces to these values myself, but since most data and software is dynamic and only some (var)char fields will get appended and some don't, there is no way of telling which columns should be appended (or prepended) and which shouldn't. For the sake of data consistency I would either like to see this bug fixed, or -if it is no bug but a feature- see a configuration option being introduced to overrule this trimming. Reproduce code: --- In php the following code will return trimmed values: $db= mssql_connect('server','user','pass'); $result= mssql_query("SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %'"); $a = mssql_fetch_assoc($result); print_r($a); but commandline this values are not being trimmed: # tsql -S server -U user -P pass locale is "C" charset is "ANSI_X3.4-1968" Msg 5703, Level 0, State 1, Server NTS1, Line 0 Changed language setting to us_english. 1> SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %' 2> go medewerker '100 ' (size=8) 1> SELECT TOP 1 rtrim(medewerker) as trimmed_medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE '% %' 2> go trimmed_medewerker '100' (size=3) (I added single quotes around the results and wrote the sizes behind it so you can see the difference between the two queries) Expected result: Obviously I expect to get exactly the same data that is stored in the database instead of modified (trimmed) data. -- Edit this bug report at http://bugs.php.net/?id=2577
#25874 [Opn->Bgs]: var_export does not output valid code
ID: 25874 Updated by: [EMAIL PROTECTED] Reported By: fire at firepages dot com dot au -Status: Open +Status: Bogus Bug Type: Variables related Operating System: XP PHP Version: 4.3.3 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 The trailing comma while unusual is perfectly valid and the code evaluates correctly. Previous Comments: [2003-10-14 22:21:48] fire at firepages dot com dot au Description: output from var_export($var,true) has trailing comma so you have to strip that manually before utilising the returned string. the manual example shows this behaviour so perhaps its a feature ? Reproduce code: --- $yaks = array( 'dfdf'=>'a' , 'b' , 'c' , 'd' ) ; echo '$llama = ' . var_export( $yaks , true ) . ' ;' ; Expected result: $llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd' ) ; Actual result: -- $llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd', ) ; -- Edit this bug report at http://bugs.php.net/?id=25874&edit=1
#25798 [NoF->Opn]: forever-running or no-error-abort in preg_match
ID: 25798 User updated by: musha dot yoshinori at nifty dot ne dot jp Reported By: musha dot yoshinori at nifty dot ne dot jp -Status: No Feedback +Status: Open Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.3.3 New Comment: I am sorry for late. I was busy for business. Now, I checked the bug using the latest version of PHP, PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. By the bug, I feel that it is difficult to describe regular expressions avoiding the bug in preg_match. I want to describe regular expressions more freely. By the way, in the latest version, phpinfo() shows "Apache Version: Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows "4.3.3". Is it OK? Thank you. Previous Comments: [2003-10-14 20:31:51] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-10 11:50:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp I know that it depends on platforms. I use PHP on Windows XP Pro, Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match with the same regular expression works fine on other platform. Thank you. [2003-10-08 22:36:43] [EMAIL PROTECTED] Works fine here on Linux, what locale are you using? [2003-10-08 14:04:09] musha dot yoshinori at nifty dot ne dot jp Description: PHP aborts without any message or runs forever in below case. Platform: Windows XP Pro, Apache2.0.46, PHP4.3.3 For example, in preg_match('/a(?:.)+z/',$str,$match), the length of string matched between 'a' and 'z' is more than approximately 1KB. It always appears. According to the length, PHP aborts without any message or runs forever. It also appears in preg_match('/a(?>.)+z/',$str,$match), but does not appear in preg_match('/a(.)+z/',$str,$match) and preg_match('/a.+z/',$str,$match). Actually, I want to use preg_match_all('/]*>((?>.(?!<\/tr>))+.)<\/tr>/is',$str,$matches) and so on. Reproduce code: --- $str =<
#25874 [NEW]: var_export does not output valid code
From: fire at firepages dot com dot au Operating system: XP PHP version: 4.3.3 PHP Bug Type: Variables related Bug description: var_export does not output valid code Description: output from var_export($var,true) has trailing comma so you have to strip that manually before utilising the returned string. the manual example shows this behaviour so perhaps its a feature ? Reproduce code: --- $yaks = array( 'dfdf'=>'a' , 'b' , 'c' , 'd' ) ; echo '$llama = ' . var_export( $yaks , true ) . ' ;' ; Expected result: $llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd' ) ; Actual result: -- $llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd', ) ; -- Edit bug report at http://bugs.php.net/?id=25874&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25874&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25874&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25874&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25874&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25874&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25874&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25874&r=support Expected behavior: http://bugs.php.net/fix.php?id=25874&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25874&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25874&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25874&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25874&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25874&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25874&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25874&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25874&r=float
#20006 [Ana->Ver]: cannot use 2 database connections
ID: 20006 Updated by: [EMAIL PROTECTED] Reported By: kezal at mail dot ru -Status: Analyzed +Status: Verified Bug Type: OCI8 related Operating System: Linux (RH) PHP Version: 4.3.3RC4-dev Previous Comments: [2002-10-21 08:48:34] [EMAIL PROTECTED] Also, once you're there, Thies, what could we about maintaining the connections over the database reloads as reported in several posts earlier. I am, refering for the cases when, after restarting Oracle you'd need to necessarely restart apache. I tried to research on it and it seems to me that this is doable by controlling the connection via Zend handlers (or something like that) but I am still learning about Zend Engine, so couldn't fix that part yet. Maxim Maletsky [2002-10-21 05:29:05] [EMAIL PROTECTED] i could verfy that indeed there is a problem. please add a 2nd tnsname for the same database and do $a = ocilogon(.., .., tns1); $b = ocilogon(.., .., tns2); to get two independent database connections. i really hope that i find some time to fix this soon!! [2002-10-21 04:08:02] kezal at mail dot ru If you have created 2nd connection, you cannot use 1st connection. I think 2nd connection doesn't create its own Oracle cursor till first oraparse/exec executed === cut === //1. Connect and exec OK. $conn_id1 = ociLogon("test","test123"); $stmt1 = ociparse($conn_id1,"select count(*) from tbl_lang_"); ociexecute($stmt1); //2. Connect OK. $conn_id2 = ociLogon("book1","book123"); //3. Exec fails! $stmt1 = ociparse($conn_id1,"select count(*) from tbl_lang_"); ociexecute($stmt1); === cut === -- Edit this bug report at http://bugs.php.net/?id=20006&edit=1
#19434 [Opn->Fbk]: oci8 + ldap -> crash
ID: 19434 Updated by: [EMAIL PROTECTED] Reported By: ronan dot salmon at staff dot ittralee dot ie -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: redhat 7.3 PHP Version: 4.3.3RC4-dev New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-07-17 03:40:47] ronan dot salmon at staff dot ittralee dot ie Sorry, I don't know what I've done yesterday but in fact LDAP doesn't work alone anymore. Here the script : Wrong username or password!\n"; exit; } ?> I'm using the same php as yesterday. [~/php]# gdb ./php4-STABLE-200307160330/sapi/cgi/php login.php (gdb) run login.php Starting program: /root/php/php4-STABLE-200307160330/sapi/cgi/php login.php [New Thread 16384 (LWP 23469)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 23469)] 0x40a71a34 in _int_free () from /lib/libc.so.6 (gdb) bt #0 0x40a71a34 in _int_free () from /lib/libc.so.6 #1 0x40a709cc in free () from /lib/libc.so.6 #2 0x08065d81 in zif_ldap_get_entries (ht=2, return_value=0x8208040, this_ptr=0x0, return_value_used=1, tsrm_ls=0x40d76440) at /root/php/php4-STABLE-200307160330/ext/ldap/ldap.c:953 #3 0x0813ce45 in execute (op_array=0x8203028, tsrm_ls=0x81876b0) at /root/php/php4-STABLE-200307160330/Zend/zend_execute.c:1616 #4 0x0812f7f1 in zend_execute_scripts (type=8, tsrm_ls=0x81876b0, retval=0x0, file_count=3) at /root/php/php4-STABLE-200307160330/Zend/zend.c:886 #5 0x08106305 in php_execute_script (primary_file=0xb980, tsrm_ls=0x81876b0) at /root/php/php4-STABLE-200307160330/main/main.c:1685 #6 0x08142609 in main (argc=2, argv=0xba14) at /root/php/php4-STABLE-200307160330/sapi/cgi/cgi_main.c:1542 #7 0x40a195cd in __libc_start_main () from /lib/libc.so.6 [2003-07-16 14:31:31] [EMAIL PROTECTED] Can you try and reduce your script to smallest possible that causes the crash? (like with only the ldap stuff?) [2002-09-26 20:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Reduce your configure options to bare minimum, only use --with-apxs, --with-oci8 and --with-ldap and don't compile them as shared! Do this using the latest snapshot above. [2002-09-16 07:13:50] [EMAIL PROTECTED] Oracle has it's own ldap stuff. You can't compile both openldap and oracle together. But you don't need to: --with-ldap=/home/oracle/Oracle-9.0.1 works too. [2002-09-16 06:49:24] ronan dot salmon at staff dot ittralee dot ie php-4.2.3 apache-1.3.23-14 redhat 7.3 kernel 2.4.18-10 i686 oracle 9.0.1 openldap 2.0.23 Configure command : './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-oci8=shared,/home/oracle/Oracle-9.0.1' '--enable-sigchild' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--with-apxs=/usr/sbin/apxs' If I use l
#17908 [Asn->Fbk]: Can't retrieve info using OCIColumnIsNULL()
ID: 17908 Updated by: [EMAIL PROTECTED] Reported By: ThorpeJ at gao dot gov -Status: Assigned +Status: Feedback Bug Type: OCI8 related Operating System: Linux 7.1 PHP Version: 4.0CVS-2002-06-21 Assigned To: maxim New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2002-10-20 15:33:55] [EMAIL PROTECTED] true, actually, what i noticed is that if you do a fetch *before* calling OCIColumnIsNULL() you then get the right results. /**/ $conn = OCILogon($user, $pwd, $db); $stmt = OCIParse($conn, "select * from $table"); OCIExecute($stmt); $nrows = OCIFetchStatement($stmt, $res); // adding this $ncols = OCINumCols($stmt); for ( $i = 1; $i <= $ncols; $i++ ) { echo "NAME: " . OCIColumnName($stmt,$i) . ""; echo "TYPE: " . OCIColumnType($stmt,$i) . ""; echo "SIZE: " . OCIColumnSize($stmt,$i) . ""; echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does not return any information } /**/ Will go to fix that. [2002-06-21 14:20:29] ThorpeJ at gao dot gov I've tried using OCIColumnIsNULL() to retrieve info on which fields were NULL/NOT NULL in an Oracle database table, and the function did not return anything (using OCIColumnName, OCIColumnType, and OCIColumnSize in the same program worked fine). The script below is a simple example: /**/ $conn = OCILogon($user, $pwd, $db); $stmt = OCIParse($conn, "select * from $table"); OCIExecute($stmt); $ncols = OCINumCols($stmt); for ( $i = 1; $i <= $ncols; $i++ ) { echo "NAME: " . OCIColumnName($stmt,$i) . ""; echo "TYPE: " . OCIColumnType($stmt,$i) . ""; echo "SIZE: " . OCIColumnSize($stmt,$i) . ""; echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does not return any information } /**/ -- Edit this bug report at http://bugs.php.net/?id=17908&edit=1
#17381 [Asn->Bgs]: OCI fetch routines not working with UTF8 DB
ID: 17381 Updated by: [EMAIL PROTECTED] Reported By: robert dot earls at lsi dot co dot uk -Status: Assigned +Status: Bogus Bug Type: OCI8 related Operating System: Win NT PHP Version: 4.2.1 Assigned To: maxim New Comment: Too old version (we're at 4.3.3 now) and also, the environment variables HAVE to be set in the shell, NOT in the script. They won't work otherwise. Previous Comments: [2002-05-23 06:50:05] robert dot earls at lis dot co dot uk Can I just point out that I have used putenv, to set NLS_LANG in the example, because I thought that the system-wide environment variable $NLS_LANG was not being picked up. It is currently set to "American_America.UTF8". [2002-05-23 05:32:37] robert dot earls at lsi dot co dot uk I seem to be unable to return un-corrupted data from a UTF8 Oracle database. Consider this example:- (appologies for debugging) "; print $mycolumndump; print ""; print mb_detect_encoding($mycolumn, "auto"); print ""; print mb_internal_encoding(); print ""; print_r( mb_get_info("all")); } ?> e.g. If mycolumn contains a single UTF8 character E594B4 (three bytes) I get the result:- found:bf {upsidedown question mark} len=1 Typ=1 Len=3 228,148,180 EUC-JP UTF-8 - I would have expected to see: found:e594b4 {a japanese glyph} len=3 I suppose the question is, does the OCI interface work correctly with multi-byte strings? -- Edit this bug report at http://bugs.php.net/?id=17381&edit=1
#17897 [Com]: POST form variables are empty
ID: 17897 Comment by: will at muppetmasters dot com Reported By: hofmann at isl dot org Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.2.1 New Comment: air01 seems to be correct. the $_POST built-in variable / superglobal / whatever you want to call it doesn't work properly with register_globals set to 'off', which is ironic since it is recommended for good practice that you turn it off. advice is to leave it on until they fix this problemvery irritating! :-) Previous Comments: [2003-06-16 15:23:50] sbeam at syxyz dot net to "air01 at gmx dot de" you will notice if you read the original bug report it is about $_POST and therefore has nothing to do with register_globals. confirmed that BorisATCrazySnowBoarder.com's solution of adding AddType application/x-httpd-php .php to the httpd.conf file works. This is on a RedHat 9 system (with the stock Apache 2.0.40 rpm and PHP4.2.2), which does not come with that directive by default. [2003-02-04 05:59:50] dave at nicedayin dot co dot uk just to say thanks, this thread has just solved a problem with an ASP based system I am writing. Dreamweaver MX places form actions in as script sources by default, and so does not always put full url in the action field. As such all my post variables dissapeared, then I found this form, hard coded the action page and it worked ! [2003-01-03 07:40:16] air01 at gmx dot de Following extraction helped me to solve the problem that, variables are missing in the *.php after submition. >>Hi there... The problem is actually that in PHP 4.2, Register Globals is automatically defaulted to OFF. This means that variables that were normally in the global space such as GET and POST variables are no longer in the global space by default. PHP Announcement: http://www.php.net/release_4_2_0.php You can still force the old default behavior by changing the php.ini file and set the value for register_globals to "On". This will allow you to access the variables as they are named in the forms Documentation: http://www.php.net/manual/en/configuration.php#ini.register-globals << By the way, I found this Information on expert-exchange.com http://www.experts-exchange.com/Web/Web_Languages/PHP/Q_20293768.html My configuration: PHP 4.2.3 Apache 2.0.43 Windows 2k [2002-12-13 21:25:05] donny at net-yan dot com I think the problem is PHP4. Because I installed PHP on both Apache and IIS of W2k. I got the same problem. The following are the test program (test.php). TEST I always get empty Arrays. I never imagine that such simple function have bugs in PHP, or I know to little about the PHP settings! Who can HELP!!! My system cannot progress!!! [2002-11-18 03:03:47] hofmann at isl dot org ok the solution to my problem is simple - I am using AddOutputFilter PHP;INCLUDES .php so the post variables are missing - thats because you need also to set AddInputFilter PHP .php otherwise Apache2 will not forward the POST vars! 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/17897 -- Edit this bug report at http://bugs.php.net/?id=17897&edit=1
#25863 [Opn->Fbk]: The specified CGI application misbehaved ...
ID: 25863 Updated by: [EMAIL PROTECTED] Reported By: salmanarshad2000 at yahoo dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows XP, 2000 PHP Version: 4.3.3 New Comment: Please provide short test case (all settings, script(s) whatever else is needed to reproduce this) so we can reproduce this ourselves. Previous Comments: [2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com Description: This bug or issue has been around for quite a while and seems like nobody cares. The bug list is filled with hundreds of complains about the "The specified CGI application misbehaved ..." error each time these people have BOGUSed or CLOSEd saying things like "The version you are using is too old, please try the latest version ...", "This is not a php bug, please go to ...", "Not enough evidence ..." or "Problem with Windows, not PHP". Quite a few versions of php have been released in the meanwhile, but this issue hasn't been fixed, people who upgrade their php installation come back with the same complains. I see no good reason for this ignorance. Problem Statement - When browsing a php application, the IIS server randomly throws the error message: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Observations This happened only when: - PHP.exe is used as a CGI on IIS - The php scripts contained 2 or more frames (e.g. phpMyAdmin) - MySQL operation was executed (update, insert, delete etc.) - header("Location: ...") is used to redirect user after a MySQL operation to a page that also performs a MySQL operation - The pages are viewed from local computer - A very fast computer is used This did not happened when: - Apache server for windows with php support was used - The php scripts contained 2 or more frames but all frames contained php scripts with Hello World and a random number - Frequency of errors was much lesser when same pages were accessed from the network - Pentium 2, 300 MHz was used (a slow computer) History --- Following bugs are all related to this problem. This is just a reminder for the fact that this issue has been discussed quite a few times and it is still present. People also found these interesting things that might help to get the problem solved. - BugID #25567 getting errors when doing a mysql_db_query() and then header("location") - BugID #24916 header("location") - BugID #23208 using two or more frames - BugID #19381 no details :( - BugID #19676 works on one (slow) system but does not work on other - BugID #18901 header("location") after delete or update, error occurs under under load - BugID #16313 header("location") and db operations - BugID #23050 mysql_query() followed by header("location") - BugID #17468 header("location") - BugID #9852 thousands of lines describing the problem, including frames, manually slowing down the script, pages work from outside the machine nut not locally, two database connections in rapid succession etc Things that have been said earlier -- "This is a problem with Microsoft OS" No this is not, it works on exact same OS running on slower hardware or when the application is accessed across a network. And even if it is, the developers should try to find a work around instead of blaming M$ and telling it to fix it. After all, when you develop some app for an environment, you don't change the environment to suit your app (although sometimes it is easier to do so). "This is not a php bug" Well this could be right, since there is one other suspect, MySQL. But somebody please figure out where the problem is? Also, MySQL is now an integral part of php so problem could lie in the integration part. My Opinion --- May be php.exe is not fast enough to keep up with the pace at which IIS can throw requests at it. Or ... may be it is a problem with the MySQL connections ... attempting to create connections too quickly may be the cause. Users having same problem please feel free to contribute with their observations and suggestions. -- Edit this bug report at http://bugs.php.net/?id=25863&edit=1
#23220 [Fbk->NoF]: fgets() causes warning while reading data via SSL channel (HTTPS)
ID: 23220 Updated by: [EMAIL PROTECTED] Reported By: storozhilov at mail dot ru -Status: Feedback +Status: No Feedback Bug Type: Filesystem function related Operating System: FreeBSD 4.8 PHP Version: 4-STABLE-200307070330 Assigned To: wez New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-10-08 07:30:39] [EMAIL PROTECTED] Could you try the next stable snapshot (due in a few minutes)? I comitted a fix for a different bug that might make a difference to this one. If it hasn't fixed it, could you post an https:// URL that reproduces the problem, so that I can investigate further? [2003-09-24 11:36:55] chris dot edwards at obinet dot com Getting the exact same error. Same OS, same version of PHP. Changing the length of the string offered no changes. I still get: SSL: fatal protocol error I'm getting this for fread() and fgets(). [2003-08-21 20:25:22] info at splendense dot nl Using '$buff = fgets ($f, 355);' does not give any error, however 356 does for me (php 4.3.2 solaris). My script seems to work fine but maybe a response string greater than 355 chars will not work?!? [2003-08-21 20:18:33] scottm at spamcop dot net I've not verified this patch will work and I'll hopefully test it tomorrow. I believe it is reaching the end of the file and nr_bytes is returning 0 and this is being caught by an if statement which should be looking for -1. --- network.c Thu Aug 21 21:06:43 2003 +++ network.c.patched Thu Aug 21 21:13:09 2003 @@ -1011,13 +1011,14 @@ do { nr_bytes = SSL_read(sock->ssl_handle, buf, count); - if (nr_bytes <= 0) { + if (nr_bytes < 0) { retry = handle_ssl_error(stream, nr_bytes TSRMLS_CC); if (retry == 0 && !SSL_pending(sock->ssl_handle)) { stream->eof = 1; } } else { - /* we got the data */ + /* we got the data */ + stream->eof = 1; break; } } while (retry); [2003-08-05 09:43:36] uk at access dot lv php4.3.2 configured with-openssl if ($f = fopen('https://site', 'r')) { while (!feof($f)) { $buff = fgets ($f, 1024); echo $buff; } } fclose ($f); Warning: fgets(): SSL: fatal protocol error if i read just some bits then no error. 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/23220 -- Edit this bug report at http://bugs.php.net/?id=23220&edit=1
#25798 [Fbk->NoF]: forever-running or no-error-abort in preg_match
ID: 25798 Updated by: [EMAIL PROTECTED] Reported By: musha dot yoshinori at nifty dot ne dot jp -Status: Feedback +Status: No Feedback Bug Type: PCRE related Operating System: Windows XP Pro PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-10-10 11:50:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp I know that it depends on platforms. I use PHP on Windows XP Pro, Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match with the same regular expression works fine on other platform. Thank you. [2003-10-08 22:36:43] [EMAIL PROTECTED] Works fine here on Linux, what locale are you using? [2003-10-08 14:04:09] musha dot yoshinori at nifty dot ne dot jp Description: PHP aborts without any message or runs forever in below case. Platform: Windows XP Pro, Apache2.0.46, PHP4.3.3 For example, in preg_match('/a(?:.)+z/',$str,$match), the length of string matched between 'a' and 'z' is more than approximately 1KB. It always appears. According to the length, PHP aborts without any message or runs forever. It also appears in preg_match('/a(?>.)+z/',$str,$match), but does not appear in preg_match('/a(.)+z/',$str,$match) and preg_match('/a.+z/',$str,$match). Actually, I want to use preg_match_all('/]*>((?>.(?!<\/tr>))+.)<\/tr>/is',$str,$matches) and so on. Reproduce code: --- $str =<
#25825 [Asn->Csd]: Windows PHP always returns UTC time and BST as the timezone
ID: 25825 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.3 Assigned To: wez New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The problem was that putenv("TZ=...") would call tzset() in order to update the libc with the timezone information for the time related functions, but PHP would not call tzset() again when the environment was reset. I've checked in a fix for this problem, which should hopefully make things better. However, a word of warning: The environmental variables are process-wide, so changing them in a threaded environment like ISAPI may cause some gotchas in high-concurrency scenarios (eg: two threads might be playing with the same env var at the same time). I'm marking this report as closed as the next snapshots will contain the fix. If the problem is still present in those, please reopen this report. Previous Comments: [2003-10-14 18:37:33] [EMAIL PROTECTED] Yes; that is what is happening. I'll look into having PHP reset to the system default locale at the start of each request. [2003-10-14 14:22:09] pennington at rhodes dot edu Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we are running does use putenv() in the following function: /** * Is the given date/time in DST for this time zone * * Attempts to determine if a given Date object represents a date/time * that is in DST for this time zone. WARNINGS: this basically attempts to * "trick" the system into telling us if we're in DST for a given time zone. * This uses putenv() which may not work in safe mode, and relies on unix time * which is only valid for dates from 1970 to ~2038. This relies on the * underlying OS calls, so it may not work on Windows or on a system where * zoneinfo is not installed or configured properly. * * @access public * @param object Date $date the date/time to test * @return boolean true if this date is in DST for this time zone */ function inDaylightTime($date) { $env_tz = ""; if(getenv("TZ")) { $env_tz = getenv("TZ"); } putenv("TZ=".$this->id); $ltime = localtime($date->getTime(), true); putenv("TZ=".$env_tz); return $ltime['tm_isdst']; } --- Are you saying that this could change the environment variable for timezone for the entire server for good (at least until IIS5 is restarted) once this code is executed? And this would affect pages that don't even include the function above? [2003-10-14 12:15:49] [EMAIL PROTECTED] The only other way to manipulate locale is via putenv(), which would change LC_* environment variable. [2003-10-14 10:29:48] pennington at rhodes dot edu I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out. The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale(). Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem? Are there any other PHP functions (other than setlocale) that manipulate the locale? [2003-10-13 18:41:27] [EMAIL PROTECTED] Do any of your scripts use setlocale() or other similar function to manipulate the locale? My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default. 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/25825 -- Edit this bug report at http://bugs.php.net/?id=25825&edit=1
#25428 [Opn->Csd]: xmlrpc_server_call_method() causes segfault
ID: 25428 Updated by: [EMAIL PROTECTED] Reported By: mfladischer at gmx dot net -Status: Open +Status: Closed Bug Type: XMLRPC-EPI related Operating System: RedHat 9 PHP Version: 5CVS-2003-09-08 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Patch applied. Previous Comments: [2003-10-14 20:09:57] web-php-bugs at sklar dot com This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the problem. diff -r1.35 xmlrpc-epi-php.c 1033c1033,1037 < set_output_options(&out, *output_opts); --- > if (argc == 3) { > set_output_options(&out, NULL); > } else { > set_output_options(&out, *output_opts); > } [2003-09-08 03:38:40] mfladischer at gmx dot net Description: When i'm trying to run a XML-RPC server (using the xml-rpc-extension) with PHP5 i get a segfault. Reproduce code: --- Expected result: system.listMethods system.methodHelp system.methodSignature system.describeMethods system.multiCall system.getCapabilities Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 19945)] 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 1033set_output_options(&out, *output_opts); (gdb) bt #0 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 #1 0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541 #2 0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687 #3 0x0829e834 in execute (op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:1267 #4 0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /linux/devel/php5/Zend/zend.c:1018 #5 0x0823f15c in php_execute_script (primary_file=0xb580) at /linux/devel/php5/main/main.c:1625 #6 0x082acea7 in main (argc=2, argv=0xb614) at /linux/devel/php5/sapi/cli/php_cli.c:910 #7 0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=25428&edit=1
#25867 [Bgs]: Sleep() no more work corectly on 4.3.3
ID: 25867 Updated by: [EMAIL PROTECTED] Reported By: plc2k at altern dot org Status: Bogus Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.3.3 New Comment: Your script works just like it should work. No bug here. Previous Comments: [2003-10-14 13:40:22] plc2k at altern dot org have you tested my example at least ? as i said it work on older version and not on the new one, so for me it's bug i see nothing on http://fr.php.net/sleep to let me know i'm wrong in my code... i posted a ot of messages in lot of forums, nobody know why it don't work ... [2003-10-14 13:31:54] plc2k at altens dot org this is not a bug ? so why it work in older version ? i spend many time and used many forums, nobody know .. so i 'm ok to read again the doc .. but ... why it work in older version ... [2003-10-14 12:33:25] [EMAIL PROTECTED] 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 .. [2003-10-14 12:29:08] plc2k at altern dot org Description: i used a sleep() function in my php page, and after an upgrade of php, this one no more work. so it work on older version of php like 4.2.0 but not on last one, like 4.3.3 Reproduce code: --- . "; sleep(2); } ?> Expected result: test . . . . . . . . . . (here the "." are add one by one every 2 seconds) Actual result: -- test. . . . . . . . . . . . . Fatal error: Maximum execution time of 30 seconds exceeded in c:\uptest2.php on line 8 (here, all the points appear at the timeout) -- Edit this bug report at http://bugs.php.net/?id=25867&edit=1
#25428 [Com]: xmlrpc_server_call_method() causes segfault
ID: 25428 Comment by: web-php-bugs at sklar dot com Reported By: mfladischer at gmx dot net Status: Open Bug Type: XMLRPC-EPI related Operating System: RedHat 9 PHP Version: 5CVS-2003-09-08 (dev) New Comment: This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the problem. diff -r1.35 xmlrpc-epi-php.c 1033c1033,1037 < set_output_options(&out, *output_opts); --- > if (argc == 3) { > set_output_options(&out, NULL); > } else { > set_output_options(&out, *output_opts); > } Previous Comments: [2003-09-08 03:38:40] mfladischer at gmx dot net Description: When i'm trying to run a XML-RPC server (using the xml-rpc-extension) with PHP5 i get a segfault. Reproduce code: --- Expected result: system.listMethods system.methodHelp system.methodSignature system.describeMethods system.multiCall system.getCapabilities Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 19945)] 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 1033set_output_options(&out, *output_opts); (gdb) bt #0 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 #1 0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541 #2 0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687 #3 0x0829e834 in execute (op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:1267 #4 0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /linux/devel/php5/Zend/zend.c:1018 #5 0x0823f15c in php_execute_script (primary_file=0xb580) at /linux/devel/php5/main/main.c:1625 #6 0x082acea7 in main (argc=2, argv=0xb614) at /linux/devel/php5/sapi/cli/php_cli.c:910 #7 0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=25428&edit=1
#25870 [Opn->Bgs]: Session variables do NOT work as expected
ID: 25870 Updated by: [EMAIL PROTECTED] Reported By: memoimyself at yahoo dot com dot br -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: Works fine for me under Windows. (using Apache 2.0.47 and a working script). Please don't reopen this, there is no bug here. Previous Comments: [2003-10-14 18:25:02] memoimyself at yahoo dot com dot br First of all, thanks a lot for taking time to reply to my post so quickly. Now, while I have not taken any offence whatsoever and can only imagine how busy you must be, I am *not* a newby and have *always* called start.php before test.php. The session variable ($_SESSION['test']) simply will *not* be registered unless I *reload* start.php (i.e. load it twice). On the start.php page I have included a link to test.php, so that the second page is only called after the first, i.e. the session variable was *supposed* to have been initialized. Perhaps this is a bug only affecting PHP under Windows? [2003-10-14 17:57:17] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Works fine, if start.php which intializes the session variable is always started before test.php, which uses it. [2003-10-14 14:51:12] memoimyself at yahoo dot com dot br Actually, I've found out that using session_register() won't help at all. What does work is if I reload the page where the session variable is set (start.php) and then open the page where the session variable is used (test.php). For obvious reasons, this is not a very convenient solution in a production environment. :-) [2003-10-14 14:27:17] memoimyself at yahoo dot com dot br Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI). [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#21532 [Opn->Fbk]: incorrect warning
ID: 21532 Updated by: [EMAIL PROTECTED] Reported By: czuma at poland dot org -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.2 Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-10-14 14:09:19] czuma at poland dot org The same problem in PHP 4.3.3. [2003-08-01 06:10:27] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-07-27 13:52:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-03-22 14:20:35] czuma at poland dot org I have checked php4-STABLE-200303221630 (PHP/4.3.2-RC) Unfortunately, it doesn't work. I still see incorrect warning. [2003-03-01 12:07:47] czuma at poland dot org I have checked php4-STABLE-200303011230 Unfortunately it doesn't work. I still see incorrect warning: "SAFE MODE Restriction in effect. The script whose uid is XXX is not allowed to access /www/user/data owned by uid 0 in /www/user/stale/table1a.php on line 3" "Line 3": $my=opendir("/www/user/data/$dat"); Probably: $dat=blabla/bleble.txt Directory "blabla" doesn't exist. I see correct and then incorrect warning. 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/21532 -- Edit this bug report at http://bugs.php.net/?id=21532&edit=1
#25827 [Opn->Bgs]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Open +Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: We only wrap around the OpenLDAP libraries. So it's definately not PHP bug -> bogus. You should report this to the openldap folks, they propably already know about it or are very willing to fix it if it's not already fixed. Please let us know what the response is so we can possibly update the used openldap libraries in the win32 binaries build. Previous Comments: [2003-10-14 14:08:51] pennington at rhodes dot edu OK, you're right, after a few minutes, I found an ldapsearch command that would work: ldapsearch -x -b "CN=_some_user_,CN=Users,DC=rhodes,DC=edu" -D "CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu" -H ldap://someserver.rhodes.edu -W The "memberof" attribute results look like this: memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=INFO_SERVICES,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Senior2006,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu Again, only 12 results were returned rather than the 13 that exist there in Active Directory. However, I've started doing a count based on attributes found by ldapsearch and Softerra's LDAPBrowser (which I think also uses openldap) and found that people missing an attibute value in ldapsearch were missing the same value in LDAPBrowser. Anyway, I think what we are down to is one of two possibilities: 1) OpenLDAP's search tool is not receiving all attribute values for a particular search; or 2) Active Directory is not supplying the missing value when queried for it using LDAP but does reply properly when Microsoft admin tools are used. I guess we could solve this if someone knows a good, freely-available, non-openldap-based LDAP search utility. Regardless, this doesn't look like a PHP bug per se, thought it could be a OpenLDAP bug that has found its way into PHP with the rest of the OpenLDAP code... [2003-10-14 12:26:58] [EMAIL PROTECTED] There is no kerberos support in PHP ldap either, and that partially works, so why would you need it with the command line binary? [2003-10-14 11:59:27] pennington at rhodes dot edu It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN, "CN=_search_value_" for the name to search for, and to bind to the Active Directory LDAP server, you have to use this string as the username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu" [2003-10-14 11:12:30] [EMAIL PROTECTED] PHP uses OpenLDAP libraries for ldap functionality in the windows binaries. So try your query with the openldap 'ldapsearch.exe' found in this package: http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip [2003-10-13 12:05:40] pennington at rhodes dot edu I obviously can't provide general access for testing to our Active Directory server, because you need an account on the Active Directory server to even search the directory, as with most LDAP servers. I find it strange that no one has seen this before, because Microsoft's Active Di
#25871 [Opn->Bgs]: imagecreatetruecolor uses memory excessively
ID: 25871 Updated by: [EMAIL PROTECTED] Reported By: bb at ii dot nl -Status: Open +Status: Bogus -Bug Type: Performance problem +Bug Type: GD related Operating System: RedHat Linux PHP Version: 4.3.3 New Comment: That's GD problem, not PHP. Report it to the GD author. Previous Comments: [2003-10-14 19:41:34] bb at ii dot nl I have read the documentation, but I could not find any reference to a maximum image size supported. The problem does indeed seem to be memory running out. When I increased the memory available to PHP to 50mb, the large images no longer terminated the script. I've changed the bug report to a 'performance problem', as I believe imagecreatetruecolor is somewhat wasteful with resources. The script terminates with a 1310x4000 image, about 5.3mpix in size, with a 25mb memory limit. Apparently imagecreatetruecolor takes almost twice the memory it should. Sorry about not investigating the memory thing sooner, before submitting. I should've thought of that myself. [2003-10-14 17:33:27] [EMAIL PROTECTED] 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 PHP crashes (probably just exists) due to reaching the memory limit and being unable to allocate additional memory. [2003-10-14 15:27:54] bb at ii dot nl Description: ImageCreateTrueColor crashes PHP if I allocate an image over ~400 pixels in size. I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible) Memory_limit is set to 26214400 Reproduce code: --- $im = imagecreatetruecolor(1500,4000); Actual result: -- PHP crashes -- Edit this bug report at http://bugs.php.net/?id=25871&edit=1
#25871 [Bgs->Opn]: imagecreatetruecolor uses memory excessively
ID: 25871 User updated by: bb at ii dot nl -Summary: imagecreatetruecolor crashes if image over 4mpix Reported By: bb at ii dot nl -Status: Bogus +Status: Open -Bug Type: Reproducible crash +Bug Type: Performance problem Operating System: RedHat Linux PHP Version: 4.3.3 New Comment: I have read the documentation, but I could not find any reference to a maximum image size supported. The problem does indeed seem to be memory running out. When I increased the memory available to PHP to 50mb, the large images no longer terminated the script. I've changed the bug report to a 'performance problem', as I believe imagecreatetruecolor is somewhat wasteful with resources. The script terminates with a 1310x4000 image, about 5.3mpix in size, with a 25mb memory limit. Apparently imagecreatetruecolor takes almost twice the memory it should. Sorry about not investigating the memory thing sooner, before submitting. I should've thought of that myself. Previous Comments: [2003-10-14 17:33:27] [EMAIL PROTECTED] 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 PHP crashes (probably just exists) due to reaching the memory limit and being unable to allocate additional memory. [2003-10-14 15:29:27] bb at ii dot nl OS is RedHat, not Debian [2003-10-14 15:27:54] bb at ii dot nl Description: ImageCreateTrueColor crashes PHP if I allocate an image over ~400 pixels in size. I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible) Memory_limit is set to 26214400 Reproduce code: --- $im = imagecreatetruecolor(1500,4000); Actual result: -- PHP crashes -- Edit this bug report at http://bugs.php.net/?id=25871&edit=1
#25825 [Opn->Asn]: Windows PHP always returns UTC time and BST as the timezone
ID: 25825 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.3 Assigned To: wez New Comment: Yes; that is what is happening. I'll look into having PHP reset to the system default locale at the start of each request. Previous Comments: [2003-10-14 14:22:09] pennington at rhodes dot edu Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we are running does use putenv() in the following function: /** * Is the given date/time in DST for this time zone * * Attempts to determine if a given Date object represents a date/time * that is in DST for this time zone. WARNINGS: this basically attempts to * "trick" the system into telling us if we're in DST for a given time zone. * This uses putenv() which may not work in safe mode, and relies on unix time * which is only valid for dates from 1970 to ~2038. This relies on the * underlying OS calls, so it may not work on Windows or on a system where * zoneinfo is not installed or configured properly. * * @access public * @param object Date $date the date/time to test * @return boolean true if this date is in DST for this time zone */ function inDaylightTime($date) { $env_tz = ""; if(getenv("TZ")) { $env_tz = getenv("TZ"); } putenv("TZ=".$this->id); $ltime = localtime($date->getTime(), true); putenv("TZ=".$env_tz); return $ltime['tm_isdst']; } --- Are you saying that this could change the environment variable for timezone for the entire server for good (at least until IIS5 is restarted) once this code is executed? And this would affect pages that don't even include the function above? [2003-10-14 12:15:49] [EMAIL PROTECTED] The only other way to manipulate locale is via putenv(), which would change LC_* environment variable. [2003-10-14 10:29:48] pennington at rhodes dot edu I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out. The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale(). Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem? Are there any other PHP functions (other than setlocale) that manipulate the locale? [2003-10-13 18:41:27] [EMAIL PROTECTED] Do any of your scripts use setlocale() or other similar function to manipulate the locale? My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default. [2003-10-13 17:53:32] pennington at rhodes dot edu Interestingly, when testing to see if this UTC display of time would happen for PHP installed as a CGI (couldn't reproduce with Apache2 or IIS5 as a CGI), I noticed that the UTC time problem does not show up right away with PHP installed as ISAPI on IIS5. Rather, when you stop the IIS service and then start it again, for a period of time, the correct time is displayed using echo date("D M j G:i:s T Y"); However, after a period of time passes (say an hour or so on a server averaging a few users at a time), the time switches to UTC and does not go back. If you stop IIS and then start it again, the time goes back to the correct time and the cycle starts again. Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because I've been having trouble getting the Windows 2000 Server, which uses PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as setting cgi.force_redirect = 0 and changing the app mapping configuration to point to the php.exe and not the php4isapi.dll but I'm not having any luck (get "not authorized to view this page" on php scripts). This method works fine on the Win2K workstation. Anyway, this is not related to the UTC time issue... 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/25825 -- Edit this bug report at http://bugs.php.net/?id=25825&edit=1
#25870 [Bgs->Opn]: Session variables do NOT work as expected
ID: 25870 User updated by: memoimyself at yahoo dot com dot br -Summary: Session variables do NOT work as expected without session_register() Reported By: memoimyself at yahoo dot com dot br -Status: Bogus +Status: Open Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: First of all, thanks a lot for taking time to reply to my post so quickly. Now, while I have not taken any offence whatsoever and can only imagine how busy you must be, I am *not* a newby and have *always* called start.php before test.php. The session variable ($_SESSION['test']) simply will *not* be registered unless I *reload* start.php (i.e. load it twice). On the start.php page I have included a link to test.php, so that the second page is only called after the first, i.e. the session variable was *supposed* to have been initialized. Perhaps this is a bug only affecting PHP under Windows? Previous Comments: [2003-10-14 17:57:17] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Works fine, if start.php which intializes the session variable is always started before test.php, which uses it. [2003-10-14 14:51:12] memoimyself at yahoo dot com dot br Actually, I've found out that using session_register() won't help at all. What does work is if I reload the page where the session variable is set (start.php) and then open the page where the session variable is used (test.php). For obvious reasons, this is not a very convenient solution in a production environment. :-) [2003-10-14 14:27:17] memoimyself at yahoo dot com dot br Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI). [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#25870 [Opn->Bgs]: Session variables do NOT work as expected without session_register()
ID: 25870 Updated by: [EMAIL PROTECTED] Reported By: memoimyself at yahoo dot com dot br -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Works fine, if start.php which intializes the session variable is always started before test.php, which uses it. Previous Comments: [2003-10-14 14:51:12] memoimyself at yahoo dot com dot br Actually, I've found out that using session_register() won't help at all. What does work is if I reload the page where the session variable is set (start.php) and then open the page where the session variable is used (test.php). For obvious reasons, this is not a very convenient solution in a production environment. :-) [2003-10-14 14:27:17] memoimyself at yahoo dot com dot br Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI). [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#25868 [Opn->Csd]: error in mail()- function
ID: 25868 Updated by: [EMAIL PROTECTED] Reported By: info at xaran dot de -Status: Open +Status: Closed Bug Type: Mail related Operating System: Win XP SP1 PHP Version: 4.3.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-10-14 13:19:31] info at xaran dot de Description: There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Reproduce code: --- There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Expected result: There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Actual result: -- There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. -- Edit this bug report at http://bugs.php.net/?id=25868&edit=1
#25862 [Opn->WFx]: mail() always return FALSE
ID: 25862 Updated by: [EMAIL PROTECTED] Reported By: thouraud at bondy dot ird dot fr -Status: Open +Status: Wont fix Bug Type: Mail related Operating System: solaris 9 PHP Version: 4.3.3 New Comment: When PHP is compiled with --enable-sigchild the return codes of executed programs are lost. Once of those programs is sendmail, since PHP cannot fetch the return code it assumes the program had failed. Hence the always FALSE return value of mail(). Normally mail() returns false only when communication between PHP & sendmail fails. Previous Comments: [2003-10-14 13:05:24] thouraud at bondy dot ird dot fr Without the --enable-sigchild configure option, it seems that mail() alwayes return TRUE. Even if the mail server returns an "unknown error" with a false email, or an "No recipients specified" with a blank first field of mail(). Is that normal ? When mail() returns FALSE ? [2003-10-14 11:13:37] [EMAIL PROTECTED] Okay, try removing the --enable-sigchild configure option and reconfigure/compile PHP. (don't forget to delete config.cache before reconfiguring!) [2003-10-14 10:44:48] thouraud at bondy dot ird dot fr the configure line is : ./configure --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache --with-config-file-path=/opt/apache/conf --with-mysql --disable-debug --enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase --enable-safe-mode --disable-magic-quotes --enable-sigchild --enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring --enable-mbregex --enable-zend-multibyte --enable-bcmath --enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus --with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd --with-iconv --with-pgsql=/opt/postgres [2003-10-14 10:34:18] [EMAIL PROTECTED] What was the configure line you used to configure PHP? [2003-10-14 08:26:31] thouraud at bondy dot ird dot fr Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit this bug report at http://bugs.php.net/?id=25862&edit=1
#25873 [Opn->Bgs]: local setting (.htaccess) of upload_max_filesize prevents file uploads to work
ID: 25873 Updated by: [EMAIL PROTECTED] Reported By: arnaud dot mlist1 at free dot fr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.2 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Apache 2 code has change quite significantly since 4.2.2 and behaviour in 4.2.2 is not applicable. Previous Comments: [2003-10-14 16:21:43] arnaud dot mlist1 at free dot fr Description: I think the problem is linked to Apache 2.0 but I am not really sure : could be the version of PHP (4.2.2) (but I cannot upgrade : it not my machine...) Everythink works as expected on Apache 1.3 with PHP 4.3.2. The problem : when trying to modify local setting of upload_max_filesize (in local .htaccess), phpinfo() shows the modification as expected, but file uploads don't work anymore (even with very small files of one byte). The function is_uploaded_file ($file) returns false in my scripts. Even when I use locally the same value as in the main php.ini, file uploads fail... If I delete the line from the .htaccess, then everything works fine. I also tried to modify locally other PHP settings to see if the problem was linked to modification of ANY local setting, but file uploads were not affected. I know I should try to run PHP 4.2.2 on my Apache 1.3, to see if things work differently, but I thought I would ask first. Thanks for anyone digging into this problem Expected result: $HTTP_POST_FILES['import_file']['tmp_name'] should not be empty Actual result: -- $HTTP_POST_FILES['import_file']['tmp_name'] is empty when local setting of upload_max_filesize is used -- Edit this bug report at http://bugs.php.net/?id=25873&edit=1
#25872 [Opn->Bgs]: Query of MS-Word char causes ISO number to show up instead of actual character
ID: 25872 Updated by: [EMAIL PROTECTED] Reported By: mrtima at aol dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Any PHP Version: 4.3.1 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. Thank you for your interest in PHP. You are probably inserting the encoded values into MySQL. Previous Comments: [2003-10-14 15:58:37] mrtima at aol dot com Description: When certain MS-Word characters such as (’) are returned from a query in MySQL and displayed to a webpage, you see ’ instead. MS-Word parenthesis = ’ Standard ASCII paranthesis = ' Reproduce code: --- //database connection params include("db_conn.php"); //the database should have a MS-Word parenthesis in it (’) $result = mysql_query("SELECT textvalue FROM anytable"); $fetch_result = mysql_fetch_object($result); //display result to a webpage echo $fetch_result->textvalue; Expected result: ’ Actual result: -- ’ -- Edit this bug report at http://bugs.php.net/?id=25872&edit=1
#21938 [Com]: Wrong error line numbers
ID: 21938 Comment by: chris at antiochwebhost dot com Reported By: arne dot brachhold at co4 dot de Status: No Feedback Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.1-dev New Comment: I too am having this problem... Example: Parse error: parse error, unexpected T_STRING, expecting ',' or ';' in /home/httpd/vhosts/soundthetrumpet.org/httpdocs/Admin_Center/Communicator.php on line 540 - There is absolutely no reason that I should be having this problem as that entire section of the file is non-php. I'm using v4.3.3 strangely enough, so I'm not sure if this is a version issue. Previous Comments: [2003-04-08 14:39:33] duerra at yahoo dot com I am having this problem is as well. It doesn't happen in all my scripts, but mainly on the larger ones. The only consistency here is that it's telling me that the error occures BEFORE it actually does, whether it's telling me 10 lines or 50 lines, though, isn't consistent. Example: //line 145 echo "something" PHP may tell me that I have an error on line 105, or something like that. This is very peculiar, but it is also very existent. Any word yet on what could be going wrong?? [2003-02-20 08:04:37] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-13 02:21:22] [EMAIL PROTECTED] What was the result when testing with CGI binary? (on command line!) I can't reproduce this with even over 1000 lines of code.. [2003-02-05 03:45:55] arne dot brachhold at co4 dot de It shows the correct line on short scripts like yours. But when I create a script, write 20 times if(isset($blubb)) { } ans then blubb(); which is now on line 88, it tells me the error is on line 66. As longer the script is as higher is the difference. Sorry at the moment i don't have the time to test this with the CGI Binary. But i can do this on weekend. [2003-02-04 18:19:09] [EMAIL PROTECTED] Using PHP 4.3.1-dev and running this script: What line is the error reported on? (using PHP CLI binary) And what about with PHP CGI binary ? For me, it says the error is on line 3, which is correct. 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/21938 -- Edit this bug report at http://bugs.php.net/?id=21938&edit=1
#25871 [Opn->Bgs]: imagecreatetruecolor crashes if image over 4mpix
ID: 25871 Updated by: [EMAIL PROTECTED] Reported By: bb at ii dot nl -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: RedHat Linux PHP Version: 4.3.3 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 PHP crashes (probably just exists) due to reaching the memory limit and being unable to allocate additional memory. Previous Comments: [2003-10-14 15:29:27] bb at ii dot nl OS is RedHat, not Debian [2003-10-14 15:27:54] bb at ii dot nl Description: ImageCreateTrueColor crashes PHP if I allocate an image over ~400 pixels in size. I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible) Memory_limit is set to 26214400 Reproduce code: --- $im = imagecreatetruecolor(1500,4000); Actual result: -- PHP crashes -- Edit this bug report at http://bugs.php.net/?id=25871&edit=1
#1 [Opn->Fbk]: Test Bugs
ID: 1 Updated by: @php.net Reported By: support at championaccess dot net -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: windows PHP Version: 4.3.2 -Assigned To: +Assigned To: support New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2003-10-14 13:23:09] support at championaccess dot net simple test of the php-web-bugs.. -- Edit this bug report at http://bugs.php.net/?id=1&edit=1
#25873 [NEW]: local setting (.htaccess) of upload_max_filesize prevents file uploads to work
From: arnaud dot mlist1 at free dot fr Operating system: Linux PHP version: 4.3.2 PHP Bug Type: Apache2 related Bug description: local setting (.htaccess) of upload_max_filesize prevents file uploads to work Description: I think the problem is linked to Apache 2.0 but I am not really sure : could be the version of PHP (4.2.2) (but I cannot upgrade : it not my machine...) Everythink works as expected on Apache 1.3 with PHP 4.3.2. The problem : when trying to modify local setting of upload_max_filesize (in local .htaccess), phpinfo() shows the modification as expected, but file uploads don't work anymore (even with very small files of one byte). The function is_uploaded_file ($file) returns false in my scripts. Even when I use locally the same value as in the main php.ini, file uploads fail... If I delete the line from the .htaccess, then everything works fine. I also tried to modify locally other PHP settings to see if the problem was linked to modification of ANY local setting, but file uploads were not affected. I know I should try to run PHP 4.2.2 on my Apache 1.3, to see if things work differently, but I thought I would ask first. Thanks for anyone digging into this problem Expected result: $HTTP_POST_FILES['import_file']['tmp_name'] should not be empty Actual result: -- $HTTP_POST_FILES['import_file']['tmp_name'] is empty when local setting of upload_max_filesize is used -- Edit bug report at http://bugs.php.net/?id=25873&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25873&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25873&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25873&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25873&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25873&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25873&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25873&r=support Expected behavior: http://bugs.php.net/fix.php?id=25873&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25873&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25873&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25873&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25873&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25873&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25873&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25873&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25873&r=float
#25872 [NEW]: Query of MS-Word char causes ISO number to show up instead of actual character
From: mrtima at aol dot com Operating system: Any PHP version: 4.3.1 PHP Bug Type: MySQL related Bug description: Query of MS-Word char causes ISO number to show up instead of actual character Description: When certain MS-Word characters such as (’) are returned from a query in MySQL and displayed to a webpage, you see ’ instead. MS-Word parenthesis = ’ Standard ASCII paranthesis = ' Reproduce code: --- //database connection params include("db_conn.php"); //the database should have a MS-Word parenthesis in it (’) $result = mysql_query("SELECT textvalue FROM anytable"); $fetch_result = mysql_fetch_object($result); //display result to a webpage echo $fetch_result->textvalue; Expected result: ’ Actual result: -- ’ -- Edit bug report at http://bugs.php.net/?id=25872&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25872&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25872&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25872&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25872&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25872&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25872&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25872&r=support Expected behavior: http://bugs.php.net/fix.php?id=25872&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25872&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25872&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25872&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25872&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25872&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25872&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25872&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25872&r=float
#25871 [Opn]: imagecreatetruecolor crashes if image over 4mpix
ID: 25871 User updated by: bb at ii dot nl Reported By: bb at ii dot nl Status: Open Bug Type: Reproducible crash -Operating System: Debian Linux +Operating System: RedHat Linux PHP Version: 4.3.3 New Comment: OS is RedHat, not Debian Previous Comments: [2003-10-14 15:27:54] bb at ii dot nl Description: ImageCreateTrueColor crashes PHP if I allocate an image over ~400 pixels in size. I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible) Memory_limit is set to 26214400 Reproduce code: --- $im = imagecreatetruecolor(1500,4000); Actual result: -- PHP crashes -- Edit this bug report at http://bugs.php.net/?id=25871&edit=1
#25871 [NEW]: imagecreatetruecolor crashes if image over 4mpix
From: bb at ii dot nl Operating system: Debian Linux PHP version: 4.3.3 PHP Bug Type: Reproducible crash Bug description: imagecreatetruecolor crashes if image over 4mpix Description: ImageCreateTrueColor crashes PHP if I allocate an image over ~400 pixels in size. I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible) Memory_limit is set to 26214400 Reproduce code: --- $im = imagecreatetruecolor(1500,4000); Actual result: -- PHP crashes -- Edit bug report at http://bugs.php.net/?id=25871&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25871&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25871&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25871&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25871&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25871&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25871&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25871&r=support Expected behavior: http://bugs.php.net/fix.php?id=25871&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25871&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25871&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25871&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25871&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25871&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25871&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25871&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25871&r=float
#25870 [Opn]: Session variables do NOT work as expected without session_register()
ID: 25870 User updated by: memoimyself at yahoo dot com dot br Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: Actually, I've found out that using session_register() won't help at all. What does work is if I reload the page where the session variable is set (start.php) and then open the page where the session variable is used (test.php). For obvious reasons, this is not a very convenient solution in a production environment. :-) Previous Comments: [2003-10-14 14:27:17] memoimyself at yahoo dot com dot br Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI). [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#25870 [Opn]: Session variables do NOT work as expected without session_register()
ID: 25870 User updated by: memoimyself at yahoo dot com dot br Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI). Previous Comments: [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#25825 [Fbk->Opn]: Windows PHP always returns UTC time and BST as the timezone
ID: 25825 User updated by: pennington at rhodes dot edu Reported By: pennington at rhodes dot edu -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.3 Assigned To: wez New Comment: Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we are running does use putenv() in the following function: /** * Is the given date/time in DST for this time zone * * Attempts to determine if a given Date object represents a date/time * that is in DST for this time zone. WARNINGS: this basically attempts to * "trick" the system into telling us if we're in DST for a given time zone. * This uses putenv() which may not work in safe mode, and relies on unix time * which is only valid for dates from 1970 to ~2038. This relies on the * underlying OS calls, so it may not work on Windows or on a system where * zoneinfo is not installed or configured properly. * * @access public * @param object Date $date the date/time to test * @return boolean true if this date is in DST for this time zone */ function inDaylightTime($date) { $env_tz = ""; if(getenv("TZ")) { $env_tz = getenv("TZ"); } putenv("TZ=".$this->id); $ltime = localtime($date->getTime(), true); putenv("TZ=".$env_tz); return $ltime['tm_isdst']; } --- Are you saying that this could change the environment variable for timezone for the entire server for good (at least until IIS5 is restarted) once this code is executed? And this would affect pages that don't even include the function above? Previous Comments: [2003-10-14 12:15:49] [EMAIL PROTECTED] The only other way to manipulate locale is via putenv(), which would change LC_* environment variable. [2003-10-14 10:29:48] pennington at rhodes dot edu I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out. The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale(). Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem? Are there any other PHP functions (other than setlocale) that manipulate the locale? [2003-10-13 18:41:27] [EMAIL PROTECTED] Do any of your scripts use setlocale() or other similar function to manipulate the locale? My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default. [2003-10-13 17:53:32] pennington at rhodes dot edu Interestingly, when testing to see if this UTC display of time would happen for PHP installed as a CGI (couldn't reproduce with Apache2 or IIS5 as a CGI), I noticed that the UTC time problem does not show up right away with PHP installed as ISAPI on IIS5. Rather, when you stop the IIS service and then start it again, for a period of time, the correct time is displayed using echo date("D M j G:i:s T Y"); However, after a period of time passes (say an hour or so on a server averaging a few users at a time), the time switches to UTC and does not go back. If you stop IIS and then start it again, the time goes back to the correct time and the cycle starts again. Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because I've been having trouble getting the Windows 2000 Server, which uses PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as setting cgi.force_redirect = 0 and changing the app mapping configuration to point to the php.exe and not the php4isapi.dll but I'm not having any luck (get "not authorized to view this page" on php scripts). This method works fine on the Win2K workstation. Anyway, this is not related to the UTC time issue... [2003-10-13 12:14:05] [EMAIL PROTECTED] Do you get the same problem running CGI? 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/25825 -- Edit this bug report at http://bugs.php.net/?id=25825&edit=1
#21532 [NoF->Opn]: incorrect warning
ID: 21532 User updated by: czuma at poland dot org Reported By: czuma at poland dot org -Status: No Feedback +Status: Open Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.2 Assigned To: wez New Comment: The same problem in PHP 4.3.3. Previous Comments: [2003-08-01 06:10:27] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-07-27 13:52:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-03-22 14:20:35] czuma at poland dot org I have checked php4-STABLE-200303221630 (PHP/4.3.2-RC) Unfortunately, it doesn't work. I still see incorrect warning. [2003-03-01 12:07:47] czuma at poland dot org I have checked php4-STABLE-200303011230 Unfortunately it doesn't work. I still see incorrect warning: "SAFE MODE Restriction in effect. The script whose uid is XXX is not allowed to access /www/user/data owned by uid 0 in /www/user/stale/table1a.php on line 3" "Line 3": $my=opendir("/www/user/data/$dat"); Probably: $dat=blabla/bleble.txt Directory "blabla" doesn't exist. I see correct and then incorrect warning. [2003-02-25 01:42:35] rohan at cs dot rmit dot edu dot au Opps, lost part of the error... it is: Warning: filemtime() [function.filemtime]: SAFE MODE Restriction in effect. The script whose uid/gid is 1/31748 is not allowed to access /home/m/malsmith/.HTMLinfo/lastmodified owned by uid/gid 31748/103 in /home/m/malsmith/.HTMLinfo/software.php on line 3 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/21532 -- Edit this bug report at http://bugs.php.net/?id=21532&edit=1
#25827 [Fbk->Opn]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 User updated by: pennington at rhodes dot edu Reported By: pennington at rhodes dot edu -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: OK, you're right, after a few minutes, I found an ldapsearch command that would work: ldapsearch -x -b "CN=_some_user_,CN=Users,DC=rhodes,DC=edu" -D "CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu" -H ldap://someserver.rhodes.edu -W The "memberof" attribute results look like this: memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=INFO_SERVICES,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Senior2006,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu Again, only 12 results were returned rather than the 13 that exist there in Active Directory. However, I've started doing a count based on attributes found by ldapsearch and Softerra's LDAPBrowser (which I think also uses openldap) and found that people missing an attibute value in ldapsearch were missing the same value in LDAPBrowser. Anyway, I think what we are down to is one of two possibilities: 1) OpenLDAP's search tool is not receiving all attribute values for a particular search; or 2) Active Directory is not supplying the missing value when queried for it using LDAP but does reply properly when Microsoft admin tools are used. I guess we could solve this if someone knows a good, freely-available, non-openldap-based LDAP search utility. Regardless, this doesn't look like a PHP bug per se, thought it could be a OpenLDAP bug that has found its way into PHP with the rest of the OpenLDAP code... Previous Comments: [2003-10-14 12:26:58] [EMAIL PROTECTED] There is no kerberos support in PHP ldap either, and that partially works, so why would you need it with the command line binary? [2003-10-14 11:59:27] pennington at rhodes dot edu It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN, "CN=_search_value_" for the name to search for, and to bind to the Active Directory LDAP server, you have to use this string as the username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu" [2003-10-14 11:12:30] [EMAIL PROTECTED] PHP uses OpenLDAP libraries for ldap functionality in the windows binaries. So try your query with the openldap 'ldapsearch.exe' found in this package: http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip [2003-10-13 12:05:40] pennington at rhodes dot edu I obviously can't provide general access for testing to our Active Directory server, because you need an account on the Active Directory server to even search the directory, as with most LDAP servers. I find it strange that no one has seen this before, because Microsoft's Active Directory is probably the most widely-used commercial LDAP server in the world. However, it is obvious that, if an attribute has 13 values when looking at it via another LDAP query tool and if PHP thinks that it has the same number of values because it creates that many keys in the array, the error must be that PHP is not setting the last value in the array (for which there already is a key) or Active Directory is not giving the last value to PHP for it to set
#25870 [NEW]: Session variables do NOT work as expected without session_register()
From: memoimyself at yahoo dot com dot br Operating system: Windows 2000 SP 4 PHP version: 4.3.3 PHP Bug Type: Session related Bug description: Session variables do NOT work as expected without session_register() Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit bug report at http://bugs.php.net/?id=25870&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25870&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25870&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25870&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25870&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25870&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25870&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25870&r=support Expected behavior: http://bugs.php.net/fix.php?id=25870&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25870&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25870&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25870&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25870&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25870&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25870&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25870&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25870&r=float
#10027 [Com]: HTTP_REFERER
ID: 10027 Comment by: paul at bladetechnology dot co dot uk Reported By: brad at youreshop dot com Status: Closed Bug Type: *Web Server problem Operating System: Linux Redhat 6.2 PHP Version: 4.0.4pl1 New Comment: The last comment was correct. It's caused by one of the Norton products (Norton Personal Firwall in my case) changing the HTTP_REFERER header into HTTP_WEFERER (elmer fudd?) and encrypting it. You can solve this by creating a rule in the firewall software to pass unaltered headers to named sites. Previous Comments: [2002-05-09 08:38:17] mn at red1 dot net I experienced the same problem using PHP4.2.0 (win32) with Apache on WinME. On the phpinfo() page HTTP_REFERER was shown as HTTP_WEFERER with a value of a string of letters. When I disabled "Norton Internet Security" the problem disappeared. What is more, scripts on a remote server which were reliant on getting data from HTTP_REFERER would not run with "NIS" enabled. Did you have a similar programme running? [2002-03-07 06:15:43] [EMAIL PROTECTED] HTTP_WEFERER has nothing todo with PHP its some data your browser gives out to the world. [2002-03-07 04:19:22] alexleu at starglory dot com Both windows2000 & FreeBSD 3.4 found SAME Problem With Apache! How to decode HTTP_WEFERER? [2001-04-29 11:50:00] [EMAIL PROTECTED] No feedback. closing [2001-03-29 11:11:48] [EMAIL PROTECTED] Works for me just fine with latest CVS. (snapshot can be found at http://snaps.php.net/ ) Which webserver are you using? Apache? --Jani 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/10027 -- Edit this bug report at http://bugs.php.net/?id=10027&edit=1
#25867 [Bgs]: Sleep() no more work corectly on 4.3.3
ID: 25867 User updated by: plc2k at altern dot org Reported By: plc2k at altern dot org Status: Bogus Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.3.3 New Comment: have you tested my example at least ? as i said it work on older version and not on the new one, so for me it's bug i see nothing on http://fr.php.net/sleep to let me know i'm wrong in my code... i posted a ot of messages in lot of forums, nobody know why it don't work ... Previous Comments: [2003-10-14 13:31:54] plc2k at altens dot org this is not a bug ? so why it work in older version ? i spend many time and used many forums, nobody know .. so i 'm ok to read again the doc .. but ... why it work in older version ... [2003-10-14 12:33:25] [EMAIL PROTECTED] 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 .. [2003-10-14 12:29:08] plc2k at altern dot org Description: i used a sleep() function in my php page, and after an upgrade of php, this one no more work. so it work on older version of php like 4.2.0 but not on last one, like 4.3.3 Reproduce code: --- . "; sleep(2); } ?> Expected result: test . . . . . . . . . . (here the "." are add one by one every 2 seconds) Actual result: -- test. . . . . . . . . . . . . Fatal error: Maximum execution time of 30 seconds exceeded in c:\uptest2.php on line 8 (here, all the points appear at the timeout) -- Edit this bug report at http://bugs.php.net/?id=25867&edit=1
#25867 [Com]: Sleep() no more work corectly on 4.3.3
ID: 25867 Comment by: plc2k at altens dot org Reported By: plc2k at altern dot org Status: Bogus Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.3.3 New Comment: this is not a bug ? so why it work in older version ? i spend many time and used many forums, nobody know .. so i 'm ok to read again the doc .. but ... why it work in older version ... Previous Comments: [2003-10-14 12:33:25] [EMAIL PROTECTED] 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 .. [2003-10-14 12:29:08] plc2k at altern dot org Description: i used a sleep() function in my php page, and after an upgrade of php, this one no more work. so it work on older version of php like 4.2.0 but not on last one, like 4.3.3 Reproduce code: --- . "; sleep(2); } ?> Expected result: test . . . . . . . . . . (here the "." are add one by one every 2 seconds) Actual result: -- test. . . . . . . . . . . . . Fatal error: Maximum execution time of 30 seconds exceeded in c:\uptest2.php on line 8 (here, all the points appear at the timeout) -- Edit this bug report at http://bugs.php.net/?id=25867&edit=1
#25868 [NEW]: error in mail()- function
From: info at xaran dot de Operating system: Win XP SP1 PHP version: 4.3.3 PHP Bug Type: Mail related Bug description: error in mail()- function Description: There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Reproduce code: --- There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Expected result: There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. Actual result: -- There is a description of the error available as a PDF- document at http://www.xaran.de/php.pdf. -- Edit bug report at http://bugs.php.net/?id=25868&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25868&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25868&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25868&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25868&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25868&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25868&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25868&r=support Expected behavior: http://bugs.php.net/fix.php?id=25868&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25868&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25868&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25868&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25868&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25868&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25868&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25868&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25868&r=float
#25862 [Fbk->Opn]: mail() always return FALSE
ID: 25862 User updated by: thouraud at bondy dot ird dot fr Reported By: thouraud at bondy dot ird dot fr -Status: Feedback +Status: Open Bug Type: Mail related Operating System: solaris 9 PHP Version: 4.3.3 New Comment: Without the --enable-sigchild configure option, it seems that mail() alwayes return TRUE. Even if the mail server returns an "unknown error" with a false email, or an "No recipients specified" with a blank first field of mail(). Is that normal ? When mail() returns FALSE ? Previous Comments: [2003-10-14 11:13:37] [EMAIL PROTECTED] Okay, try removing the --enable-sigchild configure option and reconfigure/compile PHP. (don't forget to delete config.cache before reconfiguring!) [2003-10-14 10:44:48] thouraud at bondy dot ird dot fr the configure line is : ./configure --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache --with-config-file-path=/opt/apache/conf --with-mysql --disable-debug --enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase --enable-safe-mode --disable-magic-quotes --enable-sigchild --enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring --enable-mbregex --enable-zend-multibyte --enable-bcmath --enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus --with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd --with-iconv --with-pgsql=/opt/postgres [2003-10-14 10:34:18] [EMAIL PROTECTED] What was the configure line you used to configure PHP? [2003-10-14 08:26:31] thouraud at bondy dot ird dot fr Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit this bug report at http://bugs.php.net/?id=25862&edit=1
#25866 [Bgs]: Using error_reporting() function don't change output of phpinfo() function
ID: 25866 User updated by: sfournier at dmsolutions dot ca Reported By: sfournier at dmsolutions dot ca Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 4.3.3 New Comment: Oh. Ok my bad. So the local is the runtime and master is the value from the ini. Right ? Previous Comments: [2003-10-14 12:31:13] [EMAIL PROTECTED] First is the local value, second is master. error_reporting => 1 => 2047 (local being the runtime value..) [2003-10-14 12:28:34] [EMAIL PROTECTED] It's showing the INI setting, that's totally different than a runtime setting. [2003-10-14 12:26:40] sfournier at dmsolutions dot ca Description: Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3 My php.ini contain this line: . . error_reporting = E_ALL & ~E_NOTICE . . With this simple script the error_reporting parameter is set to 2039, wich is ok. Using the same php.ini, with this other script the error_reporting parameter is *still* set to 2039. Shouldn't be set to 1 ? -- Edit this bug report at http://bugs.php.net/?id=25866&edit=1
#25794 [Opn->Asn]: Cannot open existing hash db3 file with write
ID: 25794 Updated by: [EMAIL PROTECTED] Reported By: rcovell at rolet dot com -Status: Open +Status: Assigned Bug Type: DBM/DBA related Operating System: FreeBSD 4.8 PHP Version: 4.3.4RC1 -Assigned To: +Assigned To: helly Previous Comments: [2003-10-08 10:10:39] rcovell at rolet dot com Description: Basically I cannot get php to open an existing (not created by php) db3 hash file when using either "w" or "c". It seems that php is looking for a btree format. My database is a hash file. More information: Trying to read/write information to an existing db3 database (sendmail aliases file). I can read the file just fine. But when I try to issue: $id = dba_open ("aliases5.db", "w", "db3"); I get: [Wed Oct 8 08:56:44 2003] [error] PHP Warning: dba_open(aliases5.db,w): Driver initialization failed for handler: db3: Invalid argument in /usr/local/www/data/maillists/test3.php on line 3 After further testing I dumped the entire aliases db to a text file using perl and recreated a copy of it with php: $id = dba_open ("aliases5.db", "c", "db3"); This worked when creating a new file. The file sizes where were different from the original so performed a db3_dump on the newly created php db3 database. It seems that php is defaulting to a btree format when trying to open with either w or c. My output from the db3_dump on the php created db3: VERSION=3 format=bytevalue type=btree HEADER=END And from the one that sendmail created: VERSION=3 format=bytevalue type=hash h_nelem=172 HEADER=END Reproduce code: --- //Note you need a hash database for this to fail $id = dba_open ("aliases5.db", "w", "db3"); if (!$id) { echo "dba_open failed\n"; exit; } dba_insert ("bkey", "bvalue", $id); $key = dba_firstkey ($id); while ($key != false) { echo "Key: " . $key . "->Value: " . dba_fetch ( $key, $id); $key = dba_nextkey ($id); } dba_close ($id); Expected result: To be able to insert into an existing (not created by php) db3 hash database. Actual result: -- [Wed Oct 8 08:56:44 2003] [error] PHP Warning: dba_open(aliases5.db,w): Driver initialization failed for handler: db3: Invalid argument in /usr/local/www/data/maillists/test3.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25794&edit=1
#25793 [Bgs]: special POST or GET query crashes PHP under Windows
ID: 25793 Updated by: [EMAIL PROTECTED] Reported By: valyala at tut dot by Status: Bogus Bug Type: Reproducible crash Operating System: Win2k sp3, WinXP, Win2003 PHP Version: 4.3.3RC1 - RC4 New Comment: Could not reproduce with PHP 4.3.4RC2-dev, that is. Previous Comments: [2003-10-14 12:34:52] [EMAIL PROTECTED] You're doing something wrong, I can NOT reproduce this. Make sure you actually have ONLY one php4ts.dll, etc. in your system. [2003-10-13 09:23:30] valyala at tut dot by I am using Apache 1.3.27 webserver. This string is in apache's httpd.conf file: LoadModule php4_module "c:/usr/bin/php/sapi/php4apache.dll" [2003-10-13 03:26:56] [EMAIL PROTECTED] I can not reproduce this within WinXP + Apache2 (PHP as apache2 module). What SAPI module are you using? (isapi,apache1/2, CGI binary..) Webserver? [2003-10-08 09:34:18] valyala at tut dot by Description: this query strings crashes PHP under Windows: 1[] 437378[index] 232[index]=value&something_else the query string must begins with any decimal number, following braces with optional index string. Sorry for my English :) Reproduce code: --- GET /any_php_script.php?1[] HTTP/1.1 Expected result: If my script looks like this: I expected: Array ( [1] => Array ( [0] => ) ) Actual result: -- No response headers received because request failed : ERROR_INTERNET_CONNECTION_RESET And windows shows error message: "Apache.exe has generated errors and will be closed by Windows. You will need to restart the program" -- Edit this bug report at http://bugs.php.net/?id=25793&edit=1
#25793 [Opn->Bgs]: special POST or GET query crashes PHP under Windows
ID: 25793 Updated by: [EMAIL PROTECTED] Reported By: valyala at tut dot by -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Win2k sp3, WinXP, Win2003 PHP Version: 4.3.3RC1 - RC4 New Comment: You're doing something wrong, I can NOT reproduce this. Make sure you actually have ONLY one php4ts.dll, etc. in your system. Previous Comments: [2003-10-13 09:23:30] valyala at tut dot by I am using Apache 1.3.27 webserver. This string is in apache's httpd.conf file: LoadModule php4_module "c:/usr/bin/php/sapi/php4apache.dll" [2003-10-13 03:26:56] [EMAIL PROTECTED] I can not reproduce this within WinXP + Apache2 (PHP as apache2 module). What SAPI module are you using? (isapi,apache1/2, CGI binary..) Webserver? [2003-10-08 09:34:18] valyala at tut dot by Description: this query strings crashes PHP under Windows: 1[] 437378[index] 232[index]=value&something_else the query string must begins with any decimal number, following braces with optional index string. Sorry for my English :) Reproduce code: --- GET /any_php_script.php?1[] HTTP/1.1 Expected result: If my script looks like this: I expected: Array ( [1] => Array ( [0] => ) ) Actual result: -- No response headers received because request failed : ERROR_INTERNET_CONNECTION_RESET And windows shows error message: "Apache.exe has generated errors and will be closed by Windows. You will need to restart the program" -- Edit this bug report at http://bugs.php.net/?id=25793&edit=1
#25867 [Opn->Bgs]: Sleep() no more work corectly on 4.3.3
ID: 25867 Updated by: [EMAIL PROTECTED] Reported By: plc2k at altern dot org -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows PHP Version: 4.3.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php .. Previous Comments: [2003-10-14 12:29:08] plc2k at altern dot org Description: i used a sleep() function in my php page, and after an upgrade of php, this one no more work. so it work on older version of php like 4.2.0 but not on last one, like 4.3.3 Reproduce code: --- . "; sleep(2); } ?> Expected result: test . . . . . . . . . . (here the "." are add one by one every 2 seconds) Actual result: -- test. . . . . . . . . . . . . Fatal error: Maximum execution time of 30 seconds exceeded in c:\uptest2.php on line 8 (here, all the points appear at the timeout) -- Edit this bug report at http://bugs.php.net/?id=25867&edit=1
#25866 [Bgs]: Using error_reporting() function don't change output of phpinfo() function
ID: 25866 Updated by: [EMAIL PROTECTED] Reported By: sfournier at dmsolutions dot ca Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 4.3.3 New Comment: First is the local value, second is master. error_reporting => 1 => 2047 (local being the runtime value..) Previous Comments: [2003-10-14 12:28:34] [EMAIL PROTECTED] It's showing the INI setting, that's totally different than a runtime setting. [2003-10-14 12:26:40] sfournier at dmsolutions dot ca Description: Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3 My php.ini contain this line: . . error_reporting = E_ALL & ~E_NOTICE . . With this simple script the error_reporting parameter is set to 2039, wich is ok. Using the same php.ini, with this other script the error_reporting parameter is *still* set to 2039. Shouldn't be set to 1 ? -- Edit this bug report at http://bugs.php.net/?id=25866&edit=1
#25867 [NEW]: Sleep() no more work corectly on 4.3.3
From: plc2k at altern dot org Operating system: windows PHP version: 4.3.3 PHP Bug Type: Unknown/Other Function Bug description: Sleep() no more work corectly on 4.3.3 Description: i used a sleep() function in my php page, and after an upgrade of php, this one no more work. so it work on older version of php like 4.2.0 but not on last one, like 4.3.3 Reproduce code: --- . "; sleep(2); } ?> Expected result: test . . . . . . . . . . (here the "." are add one by one every 2 seconds) Actual result: -- test. . . . . . . . . . . . . Fatal error: Maximum execution time of 30 seconds exceeded in c:\uptest2.php on line 8 (here, all the points appear at the timeout) -- Edit bug report at http://bugs.php.net/?id=25867&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25867&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25867&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25867&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25867&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25867&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25867&r=support Expected behavior: http://bugs.php.net/fix.php?id=25867&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25867&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25867&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25867&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25867&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25867&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25867&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25867&r=float
#25866 [Opn->Bgs]: Using error_reporting() function don't change output of phpinfo() function
ID: 25866 Updated by: [EMAIL PROTECTED] Reported By: sfournier at dmsolutions dot ca -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 4.3.3 New Comment: It's showing the INI setting, that's totally different than a runtime setting. Previous Comments: [2003-10-14 12:26:40] sfournier at dmsolutions dot ca Description: Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3 My php.ini contain this line: . . error_reporting = E_ALL & ~E_NOTICE . . With this simple script the error_reporting parameter is set to 2039, wich is ok. Using the same php.ini, with this other script the error_reporting parameter is *still* set to 2039. Shouldn't be set to 1 ? -- Edit this bug report at http://bugs.php.net/?id=25866&edit=1
#25827 [Opn->Fbk]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: There is no kerberos support in PHP ldap either, and that partially works, so why would you need it with the command line binary? Previous Comments: [2003-10-14 11:59:27] pennington at rhodes dot edu It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN, "CN=_search_value_" for the name to search for, and to bind to the Active Directory LDAP server, you have to use this string as the username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu" [2003-10-14 11:12:30] [EMAIL PROTECTED] PHP uses OpenLDAP libraries for ldap functionality in the windows binaries. So try your query with the openldap 'ldapsearch.exe' found in this package: http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip [2003-10-13 12:05:40] pennington at rhodes dot edu I obviously can't provide general access for testing to our Active Directory server, because you need an account on the Active Directory server to even search the directory, as with most LDAP servers. I find it strange that no one has seen this before, because Microsoft's Active Directory is probably the most widely-used commercial LDAP server in the world. However, it is obvious that, if an attribute has 13 values when looking at it via another LDAP query tool and if PHP thinks that it has the same number of values because it creates that many keys in the array, the error must be that PHP is not setting the last value in the array (for which there already is a key) or Active Directory is not giving the last value to PHP for it to set in the array. Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we not put this in feedback mode and request more information? [2003-10-13 11:55:58] [EMAIL PROTECTED] Please provide access to this 'active directory' thing. (If you can't, we can't fix it either) [2003-10-13 11:50:09] pennington at rhodes dot edu I added: var_dump($info[$i][$data][$jj]); to the output of the test script and got this output for the last two values of the array for that attribute: 0 1 11 memberof: CN=Domain Users,CN=Users,DC=rhodes,DC=edu string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu" 0 1 12 memberof: NULL Now, I know that there are 13 LDAP values for this attribute (memberof). I can see this in various LDAP tools pointed to Active Directory for this user. And, when I do a: count($info[$i][memberof]); I get 13, which is correct. As you can see, the final value has a key value in the array for this attribute, but no data is returned with that key. Obviously, PHP is not putting the last value for that attribute in the array but has created a key value to hold the data. How is this a problem in the script? Looks like a bug in PHP to me... 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/25827 -- Edit this bug report at http://bugs.php.net/?id=25827&edit=1
#25866 [NEW]: Using error_reporting() function don't change output of phpinfo() function
From: sfournier at dmsolutions dot ca Operating system: Linux PHP version: 4.3.3 PHP Bug Type: PHP options/info functions Bug description: Using error_reporting() function don't change output of phpinfo() function Description: Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3 My php.ini contain this line: . . error_reporting = E_ALL & ~E_NOTICE . . With this simple script the error_reporting parameter is set to 2039, wich is ok. Using the same php.ini, with this other script the error_reporting parameter is *still* set to 2039. Shouldn't be set to 1 ? -- Edit bug report at http://bugs.php.net/?id=25866&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25866&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25866&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25866&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25866&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25866&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25866&r=support Expected behavior: http://bugs.php.net/fix.php?id=25866&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25866&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25866&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25866&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25866&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25866&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25866&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25866&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25866&r=float
#25825 [Opn->Fbk]: Windows PHP always returns UTC time and BST as the timezone
ID: 25825 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.3 Assigned To: wez New Comment: The only other way to manipulate locale is via putenv(), which would change LC_* environment variable. Previous Comments: [2003-10-14 10:29:48] pennington at rhodes dot edu I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out. The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale(). Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem? Are there any other PHP functions (other than setlocale) that manipulate the locale? [2003-10-13 18:41:27] [EMAIL PROTECTED] Do any of your scripts use setlocale() or other similar function to manipulate the locale? My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default. [2003-10-13 17:53:32] pennington at rhodes dot edu Interestingly, when testing to see if this UTC display of time would happen for PHP installed as a CGI (couldn't reproduce with Apache2 or IIS5 as a CGI), I noticed that the UTC time problem does not show up right away with PHP installed as ISAPI on IIS5. Rather, when you stop the IIS service and then start it again, for a period of time, the correct time is displayed using echo date("D M j G:i:s T Y"); However, after a period of time passes (say an hour or so on a server averaging a few users at a time), the time switches to UTC and does not go back. If you stop IIS and then start it again, the time goes back to the correct time and the cycle starts again. Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because I've been having trouble getting the Windows 2000 Server, which uses PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as setting cgi.force_redirect = 0 and changing the app mapping configuration to point to the php.exe and not the php4isapi.dll but I'm not having any luck (get "not authorized to view this page" on php scripts). This method works fine on the Win2K workstation. Anyway, this is not related to the UTC time issue... [2003-10-13 12:14:05] [EMAIL PROTECTED] Do you get the same problem running CGI? [2003-10-13 09:52:27] pennington at rhodes dot edu [EMAIL PROTECTED] wanted to know "Which SAPI are you running? CGI? ISAPI? Apache? Something else?" I'm running ISAPI. I fail to see how this bug is identical to bug #23467, because I am getting an incorrect offset of time from GMT in addition to the incorrect time zone appearing. Unless, of course, time in general is screwed up for PHP on Win32... 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/25825 -- Edit this bug report at http://bugs.php.net/?id=25825&edit=1
#25827 [Fbk->Opn]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 User updated by: pennington at rhodes dot edu Reported By: pennington at rhodes dot edu -Status: Feedback +Status: Open Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN, "CN=_search_value_" for the name to search for, and to bind to the Active Directory LDAP server, you have to use this string as the username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu" Previous Comments: [2003-10-14 11:12:30] [EMAIL PROTECTED] PHP uses OpenLDAP libraries for ldap functionality in the windows binaries. So try your query with the openldap 'ldapsearch.exe' found in this package: http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip [2003-10-13 12:05:40] pennington at rhodes dot edu I obviously can't provide general access for testing to our Active Directory server, because you need an account on the Active Directory server to even search the directory, as with most LDAP servers. I find it strange that no one has seen this before, because Microsoft's Active Directory is probably the most widely-used commercial LDAP server in the world. However, it is obvious that, if an attribute has 13 values when looking at it via another LDAP query tool and if PHP thinks that it has the same number of values because it creates that many keys in the array, the error must be that PHP is not setting the last value in the array (for which there already is a key) or Active Directory is not giving the last value to PHP for it to set in the array. Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we not put this in feedback mode and request more information? [2003-10-13 11:55:58] [EMAIL PROTECTED] Please provide access to this 'active directory' thing. (If you can't, we can't fix it either) [2003-10-13 11:50:09] pennington at rhodes dot edu I added: var_dump($info[$i][$data][$jj]); to the output of the test script and got this output for the last two values of the array for that attribute: 0 1 11 memberof: CN=Domain Users,CN=Users,DC=rhodes,DC=edu string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu" 0 1 12 memberof: NULL Now, I know that there are 13 LDAP values for this attribute (memberof). I can see this in various LDAP tools pointed to Active Directory for this user. And, when I do a: count($info[$i][memberof]); I get 13, which is correct. As you can see, the final value has a key value in the array for this attribute, but no data is returned with that key. Obviously, PHP is not putting the last value for that attribute in the array but has created a key value to hold the data. How is this a problem in the script? Looks like a bug in PHP to me... [2003-10-12 22:10:52] [EMAIL PROTECTED] Some var_dump() here and there will reveal you why your script doesn't work. Not PHP bug. 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/25827 -- Edit this bug report at http://bugs.php.net/?id=25827&edit=1
#25862 [Opn->Fbk]: mail() always return FALSE
ID: 25862 Updated by: [EMAIL PROTECTED] Reported By: thouraud at bondy dot ird dot fr -Status: Open +Status: Feedback Bug Type: Mail related Operating System: solaris 9 PHP Version: 4.3.3 New Comment: Okay, try removing the --enable-sigchild configure option and reconfigure/compile PHP. (don't forget to delete config.cache before reconfiguring!) Previous Comments: [2003-10-14 10:44:48] thouraud at bondy dot ird dot fr the configure line is : ./configure --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache --with-config-file-path=/opt/apache/conf --with-mysql --disable-debug --enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase --enable-safe-mode --disable-magic-quotes --enable-sigchild --enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring --enable-mbregex --enable-zend-multibyte --enable-bcmath --enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus --with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd --with-iconv --with-pgsql=/opt/postgres [2003-10-14 10:34:18] [EMAIL PROTECTED] What was the configure line you used to configure PHP? [2003-10-14 08:26:31] thouraud at bondy dot ird dot fr Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit this bug report at http://bugs.php.net/?id=25862&edit=1
#25827 [Opn->Fbk]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 Updated by: [EMAIL PROTECTED] Reported By: pennington at rhodes dot edu -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: PHP uses OpenLDAP libraries for ldap functionality in the windows binaries. So try your query with the openldap 'ldapsearch.exe' found in this package: http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip Previous Comments: [2003-10-13 12:05:40] pennington at rhodes dot edu I obviously can't provide general access for testing to our Active Directory server, because you need an account on the Active Directory server to even search the directory, as with most LDAP servers. I find it strange that no one has seen this before, because Microsoft's Active Directory is probably the most widely-used commercial LDAP server in the world. However, it is obvious that, if an attribute has 13 values when looking at it via another LDAP query tool and if PHP thinks that it has the same number of values because it creates that many keys in the array, the error must be that PHP is not setting the last value in the array (for which there already is a key) or Active Directory is not giving the last value to PHP for it to set in the array. Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we not put this in feedback mode and request more information? [2003-10-13 11:55:58] [EMAIL PROTECTED] Please provide access to this 'active directory' thing. (If you can't, we can't fix it either) [2003-10-13 11:50:09] pennington at rhodes dot edu I added: var_dump($info[$i][$data][$jj]); to the output of the test script and got this output for the last two values of the array for that attribute: 0 1 11 memberof: CN=Domain Users,CN=Users,DC=rhodes,DC=edu string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu" 0 1 12 memberof: NULL Now, I know that there are 13 LDAP values for this attribute (memberof). I can see this in various LDAP tools pointed to Active Directory for this user. And, when I do a: count($info[$i][memberof]); I get 13, which is correct. As you can see, the final value has a key value in the array for this attribute, but no data is returned with that key. Obviously, PHP is not putting the last value for that attribute in the array but has created a key value to hold the data. How is this a problem in the script? Looks like a bug in PHP to me... [2003-10-12 22:10:52] [EMAIL PROTECTED] Some var_dump() here and there will reveal you why your script doesn't work. Not PHP bug. [2003-10-10 15:04:36] pennington at rhodes dot edu Description: I am querying an Active Directory server with PHP via LDAP to retrieve all of a particular user's attributes. All of that user's attributes in the LDAP directory are placed in a multi-dimensional array that I can query for a particular attribute I am interested in and return all of those values from the array by looping through that part of the array, using the correct key value. So, in other words, I am using PHP's LDAP to grab all information about a user in Active Directory and put it into a single, multi-dimensional array called $info. This array has three levels of keys, such that: $info[0][description][0] would equal Staff because that is what is set up for the description attribute for a person in Active Directory. I am then looping through the entire array looking for values set with certain keys that I am interested in, which could be holding data in any order. The problem occurs when I loop through the multi-dimensional array for attributes that share the second key, such as: $info[0][memberof] Because several different memberof attributes can be stored for a person in Active Directory, the LDAP-built array has values like: $info[0][memberof][0] = Domain Admin $info[0][memberof][1] = Finance User $info[0][memberof][2] = Local Admin and so on. If I count the number of member attributes that are actually in the LDAP server, I get a particular value, say 15. When I loop through these attributes in the array and count them up, I also get that same number. However, when I try to report back all of these attributes by printing them out, only 14 appear. In other words, while the correct number of attributes are put into the array by PHP using LDAP, one of the keys in the array has no data associated with it (and should have data associated with it). This holds true for any LDAP-created array where an LDAP attribute has more than one value associated with it. All of those values are
#25862 [Fbk->Opn]: mail() always return FALSE
ID: 25862 User updated by: thouraud at bondy dot ird dot fr Reported By: thouraud at bondy dot ird dot fr -Status: Feedback +Status: Open Bug Type: Mail related Operating System: solaris 9 PHP Version: 4.3.3 New Comment: the configure line is : ./configure --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache --with-config-file-path=/opt/apache/conf --with-mysql --disable-debug --enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase --enable-safe-mode --disable-magic-quotes --enable-sigchild --enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring --enable-mbregex --enable-zend-multibyte --enable-bcmath --enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus --with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd --with-iconv --with-pgsql=/opt/postgres Previous Comments: [2003-10-14 10:34:18] [EMAIL PROTECTED] What was the configure line you used to configure PHP? [2003-10-14 08:26:31] thouraud at bondy dot ird dot fr Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit this bug report at http://bugs.php.net/?id=25862&edit=1
#25862 [Opn->Fbk]: mail() always return FALSE
ID: 25862 Updated by: [EMAIL PROTECTED] Reported By: thouraud at bondy dot ird dot fr -Status: Open +Status: Feedback Bug Type: Mail related Operating System: solaris 9 PHP Version: 4.3.3 New Comment: What was the configure line you used to configure PHP? Previous Comments: [2003-10-14 08:26:31] thouraud at bondy dot ird dot fr Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit this bug report at http://bugs.php.net/?id=25862&edit=1
#25825 [Fbk->Opn]: Windows PHP always returns UTC time and BST as the timezone
ID: 25825 User updated by: pennington at rhodes dot edu Reported By: pennington at rhodes dot edu -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.3 Assigned To: wez New Comment: I searched through all of the PHP code in use on this machine for the setlocale() function and only found two entries, both of which were commented out. The only ISAPI filter we are using is PHP, and there is no ASP or other code on that machine. In other words, we are only using it to serve PHP pages, and none of those scripts use setlocale(). Would it be wise to unload the ASP stuff from the app mappings in IIS5 if we aren't using it so we can test to rule out ASP as the problem? Are there any other PHP functions (other than setlocale) that manipulate the locale? Previous Comments: [2003-10-13 18:41:27] [EMAIL PROTECTED] Do any of your scripts use setlocale() or other similar function to manipulate the locale? My gut feeling is that something is (and it might be ASP or some other ISAPI you have there), and that it isn't being reset back to the system default. [2003-10-13 17:53:32] pennington at rhodes dot edu Interestingly, when testing to see if this UTC display of time would happen for PHP installed as a CGI (couldn't reproduce with Apache2 or IIS5 as a CGI), I noticed that the UTC time problem does not show up right away with PHP installed as ISAPI on IIS5. Rather, when you stop the IIS service and then start it again, for a period of time, the correct time is displayed using echo date("D M j G:i:s T Y"); However, after a period of time passes (say an hour or so on a server averaging a few users at a time), the time switches to UTC and does not go back. If you stop IIS and then start it again, the time goes back to the correct time and the cycle starts again. Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because I've been having trouble getting the Windows 2000 Server, which uses PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as setting cgi.force_redirect = 0 and changing the app mapping configuration to point to the php.exe and not the php4isapi.dll but I'm not having any luck (get "not authorized to view this page" on php scripts). This method works fine on the Win2K workstation. Anyway, this is not related to the UTC time issue... [2003-10-13 12:14:05] [EMAIL PROTECTED] Do you get the same problem running CGI? [2003-10-13 09:52:27] pennington at rhodes dot edu [EMAIL PROTECTED] wanted to know "Which SAPI are you running? CGI? ISAPI? Apache? Something else?" I'm running ISAPI. I fail to see how this bug is identical to bug #23467, because I am getting an incorrect offset of time from GMT in addition to the incorrect time zone appearing. Unless, of course, time in general is screwed up for PHP on Win32... [2003-10-12 19:46:15] [EMAIL PROTECTED] This is not different to bug #23467 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/25825 -- Edit this bug report at http://bugs.php.net/?id=25825&edit=1
#25828 [Fbk->Csd]: enormus time get result from fgets via fsocketopen
ID: 25828 User updated by: scouture at novo dot ca Reported By: scouture at novo dot ca -Status: Feedback +Status: Closed Bug Type: Performance problem Operating System: win2000 PHP Version: 4.3.3 New Comment: I've changed my function using stream_select and fread instead and it works fine. So was more a coding problem than a bug finaly. Sorry for your time and thanks for your help Previous Comments: [2003-10-10 17:09:26] [EMAIL PROTECTED] Also, you really should not use stream_get_meta_data() and the unread_bytes value to drive your scripts. [2003-10-10 17:02:52] [EMAIL PROTECTED] Does the returned data include a newline? If not you should be using fread(). OR, you can use stream_select(), OR you can use stream_set_timeout() to reduce the default timeout from 60 seconds to something more appropriate to your application. [2003-10-10 16:01:34] scouture at novo dot ca Description: I was using php 4.2.2 before updating to 4.3.3. I have to talk to another application server using socket. With 4.2.2, i had my response in less than a second but it take me about 60 sec with php 4.3.3 Reproduce code: --- function getFromSocket($message){ set_time_limit (0); $res = @fsockopen ("192.168.10.5", "3734", $errno, $errstr,30); if(!$res) { exit; //some eror... } else{ fputs($res, $message); //samething, reponding server end the response by SCKEND // while (substr_count($buff, "SCKEND")!= 1) while ($bytes != "0"){ $buff .= fgets($res,4096); //$array_statusSocket = socket_get_status($res); //for 4.2.2 $array_statusSocket = stream_get_meta_data($res); $bytes = $array_statusSocket["unread_bytes"]; } fclose ($res); } return $buff; } function getMicrotime(){ list($usec, $sec) = explode(" ",microtime()); return ((float)$usec + (float)$sec); } $time_requete = getMicrotime(); $str_resultatSocket = getFromSocket("LOG|novojustice|justicenovo|intranet||SCKEND"); $time_requete2 = getMicrotime(); echo $time_requete2-$time_requete ." time"; exit; Expected result: have the result more quickly Actual result: -- took about 60sec.. -- Edit this bug report at http://bugs.php.net/?id=25828&edit=1
#25864 [Opn->Bgs]: sprintf error
ID: 25864 Updated by: [EMAIL PROTECTED] Reported By: heppevonhambach at web dot de -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: linux PHP Version: Irrelevant 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 Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2003-10-14 10:01:43] tony2001 at phpclub dot net pay attention: var_dump($n); will output float(1234567890120). i.e. your integer were automagically converted to float. so you need to use: $s = sprintf( "%0{$nL}.0f",$n ); to get expected result. look here for more info: http://www.php.net/manual/en/language.types.integer.php [2003-10-14 09:14:13] heppevonhambach at web dot de Description: looks like sprintf has problems with big numbers Reproduce code: --- $n = 1234567890123; $nL = 17; $s = sprintf( "%0{$nL}d",$n ); Expected result: 1234567890123 Actual result: -- 0001912276171 -- Edit this bug report at http://bugs.php.net/?id=25864&edit=1
#25864 [Com]: sprintf error
ID: 25864 Comment by: tony2001 at phpclub dot net Reported By: heppevonhambach at web dot de Status: Open Bug Type: Unknown/Other Function Operating System: linux PHP Version: Irrelevant New Comment: pay attention: var_dump($n); will output float(1234567890120). i.e. your integer were automagically converted to float. so you need to use: $s = sprintf( "%0{$nL}.0f",$n ); to get expected result. look here for more info: http://www.php.net/manual/en/language.types.integer.php Previous Comments: [2003-10-14 09:14:13] heppevonhambach at web dot de Description: looks like sprintf has problems with big numbers Reproduce code: --- $n = 1234567890123; $nL = 17; $s = sprintf( "%0{$nL}d",$n ); Expected result: 1234567890123 Actual result: -- 0001912276171 -- Edit this bug report at http://bugs.php.net/?id=25864&edit=1
#25864 [NEW]: sprintf error
From: heppevonhambach at web dot de Operating system: linux PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: sprintf error Description: looks like sprintf has problems with big numbers Reproduce code: --- $n = 1234567890123; $nL = 17; $s = sprintf( "%0{$nL}d",$n ); Expected result: 1234567890123 Actual result: -- 0001912276171 -- Edit bug report at http://bugs.php.net/?id=25864&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25864&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25864&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25864&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25864&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25864&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25864&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25864&r=support Expected behavior: http://bugs.php.net/fix.php?id=25864&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25864&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25864&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25864&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25864&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25864&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25864&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25864&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25864&r=float
#25860 [Opn->Fbk]: php stops working with extension=php_oci8.dll enabled
ID: 25860 Updated by: [EMAIL PROTECTED] Reported By: cchrist at csas dot cz -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Windows 2000 Server PHP Version: 4.3.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2003-10-14 08:05:58] cchrist at csas dot cz Description: I don't know, how this is possible, but I have the following error on my production environment (W2K Server, IIS 5.0, MSSQL Server 2000 SP3, PHP 4.3.3, Oracle client 9.2.1) The working config is: gd and mssql. This works without problems. But we have also scripts, accessing an oracle database via OCI. When the extension extension=php_oci8.dll is enabled, after a few hours, PHP stops producing output and after a timeout the process is terminated by IIS. Does anybody know a cure for that behaviour? This seems to be known already in PHP Version 4.0.4 (see http://bugs.php.net/bug.php?id=7575&edit=2) kind regards Christoph Christ -- Edit this bug report at http://bugs.php.net/?id=25860&edit=1
#25861 [Opn->Bgs]: bug in php 4.2
ID: 25861 Updated by: [EMAIL PROTECTED] Reported By: kailash at sarksoft dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: redhat 9.0 PHP Version: 4.3.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. PHP 4.3.3 is the latest release. Previous Comments: [2003-10-14 08:21:39] kailash at sarksoft dot com Description: I am using register_shutdown_function which is not working under php-4.2.2-17 httpd-2.0.40-21 Redhat 9.0 The function does not getting called at all. Also there are no errors reported in error_log as specified in php manual. Apparently the php script seems to working on mod_php4-4.3.1-24 apache-1.3.27-38 Suse 8.2 Here there is a error in error_log as per php manual PHP Fatal error: Unknown(): Unable to open testDW.php in Unknown on line 0 This is the code I am using to check for download from broswer #test.php #testDW.php -- Edit this bug report at http://bugs.php.net/?id=25861&edit=1
#25863 [NEW]: The specified CGI application misbehaved ...
From: salmanarshad2000 at yahoo dot com Operating system: Windows XP, 2000 PHP version: 4.3.3 PHP Bug Type: IIS related Bug description: The specified CGI application misbehaved ... Description: This bug or issue has been around for quite a while and seems like nobody cares. The bug list is filled with hundreds of complains about the "The specified CGI application misbehaved ..." error each time these people have BOGUSed or CLOSEd saying things like "The version you are using is too old, please try the latest version ...", "This is not a php bug, please go to ...", "Not enough evidence ..." or "Problem with Windows, not PHP". Quite a few versions of php have been released in the meanwhile, but this issue hasn't been fixed, people who upgrade their php installation come back with the same complains. I see no good reason for this ignorance. Problem Statement - When browsing a php application, the IIS server randomly throws the error message: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Observations This happened only when: - PHP.exe is used as a CGI on IIS - The php scripts contained 2 or more frames (e.g. phpMyAdmin) - MySQL operation was executed (update, insert, delete etc.) - header("Location: ...") is used to redirect user after a MySQL operation to a page that also performs a MySQL operation - The pages are viewed from local computer - A very fast computer is used This did not happened when: - Apache server for windows with php support was used - The php scripts contained 2 or more frames but all frames contained php scripts with Hello World and a random number - Frequency of errors was much lesser when same pages were accessed from the network - Pentium 2, 300 MHz was used (a slow computer) History --- Following bugs are all related to this problem. This is just a reminder for the fact that this issue has been discussed quite a few times and it is still present. People also found these interesting things that might help to get the problem solved. - BugID #25567 getting errors when doing a mysql_db_query() and then header("location") - BugID #24916 header("location") - BugID #23208 using two or more frames - BugID #19381 no details :( - BugID #19676 works on one (slow) system but does not work on other - BugID #18901 header("location") after delete or update, error occurs under under load - BugID #16313 header("location") and db operations - BugID #23050 mysql_query() followed by header("location") - BugID #17468 header("location") - BugID #9852 thousands of lines describing the problem, including frames, manually slowing down the script, pages work from outside the machine nut not locally, two database connections in rapid succession etc Things that have been said earlier -- "This is a problem with Microsoft OS" No this is not, it works on exact same OS running on slower hardware or when the application is accessed across a network. And even if it is, the developers should try to find a work around instead of blaming M$ and telling it to fix it. After all, when you develop some app for an environment, you don't change the environment to suit your app (although sometimes it is easier to do so). "This is not a php bug" Well this could be right, since there is one other suspect, MySQL. But somebody please figure out where the problem is? Also, MySQL is now an integral part of php so problem could lie in the integration part. My Opinion --- May be php.exe is not fast enough to keep up with the pace at which IIS can throw requests at it. Or ... may be it is a problem with the MySQL connections ... attempting to create connections too quickly may be the cause. Users having same problem please feel free to contribute with their observations and suggestions. -- Edit bug report at http://bugs.php.net/?id=25863&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25863&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25863&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25863&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25863&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25863&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25863&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25863&r=support Expected behavior: http://bugs.php.net/fix.php?id=25863&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25863&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25863&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25863&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25863&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25863&r=dst
#25862 [NEW]: mail() always return FALSE
From: thouraud at bondy dot ird dot fr Operating system: solaris 9 PHP version: 4.3.3 PHP Bug Type: Mail related Bug description: mail() always return FALSE Description: The mail() function always return FALSE. Even if the mail is sent ! Test with the sun's sendmail and postfix 2.0.16. The mail can go out with no problem. The result get the same safe_mode or not. apache 1.3.28 with php as a module Reproduce code: --- " ; if ($ret) { print 'OK' ; } else { print 'KO' ; } ?> Expected result: if we can send mail to [EMAIL PROTECTED] then OK and [EMAIL PROTECTED] receive the mail. if any error to sent mail then KO and no mail ! Actual result: -- always KO but the mail are been received ! -- Edit bug report at http://bugs.php.net/?id=25862&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25862&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25862&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25862&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25862&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25862&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25862&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25862&r=support Expected behavior: http://bugs.php.net/fix.php?id=25862&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25862&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25862&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25862&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25862&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25862&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25862&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25862&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25862&r=float
#25861 [NEW]: bug in php 4.2
From: kailash at sarksoft dot com Operating system: redhat 9.0 PHP version: 4.3.1 PHP Bug Type: Scripting Engine problem Bug description: bug in php 4.2 Description: I am using register_shutdown_function which is not working under php-4.2.2-17 httpd-2.0.40-21 Redhat 9.0 The function does not getting called at all. Also there are no errors reported in error_log as specified in php manual. Apparently the php script seems to working on mod_php4-4.3.1-24 apache-1.3.27-38 Suse 8.2 Here there is a error in error_log as per php manual PHP Fatal error: Unknown(): Unable to open testDW.php in Unknown on line 0 This is the code I am using to check for download from broswer #test.php #testDW.php -- Edit bug report at http://bugs.php.net/?id=25861&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25861&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25861&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25861&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25861&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25861&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25861&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25861&r=support Expected behavior: http://bugs.php.net/fix.php?id=25861&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25861&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25861&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25861&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25861&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25861&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25861&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25861&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25861&r=float
#25860 [NEW]: php stops working with extension=php_oci8.dll enabled
From: cchrist at csas dot cz Operating system: Windows 2000 Server PHP version: 4.3.3 PHP Bug Type: OCI8 related Bug description: php stops working with extension=php_oci8.dll enabled Description: I don't know, how this is possible, but I have the following error on my production environment (W2K Server, IIS 5.0, MSSQL Server 2000 SP3, PHP 4.3.3, Oracle client 9.2.1) The working config is: gd and mssql. This works without problems. But we have also scripts, accessing an oracle database via OCI. When the extension extension=php_oci8.dll is enabled, after a few hours, PHP stops producing output and after a timeout the process is terminated by IIS. Does anybody know a cure for that behaviour? This seems to be known already in PHP Version 4.0.4 (see http://bugs.php.net/bug.php?id=7575&edit=2) kind regards Christoph Christ -- Edit bug report at http://bugs.php.net/?id=25860&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25860&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25860&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25860&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25860&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25860&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25860&r=support Expected behavior: http://bugs.php.net/fix.php?id=25860&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25860&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25860&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25860&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25860&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25860&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25860&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25860&r=float
#24687 [Opn->WFx]: Fatal error: Only variables or references can be returned by reference
ID: 24687 Updated by: [EMAIL PROTECTED] Reported By: nologic at pchome dot com dot tw -Status: Open +Status: Wont fix Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS New Comment: Fix your scripts. Previous Comments: [2003-08-16 04:14:19] jan at horde dot org Any idea yet if this will be fixed/addressed or should we start converting scripts to not use referenced return type or build variables that get returned? [2003-07-24 03:16:39] mikkel at linet dot dk I have the same problem with PHP5 snap 200307240730, PEAR DB will not work, as many functions has "&" in front of them. So a "return new DB_Result" does not work. Mayby this should only be a "notice" instead of a "fatal" error. [2003-07-22 11:53:29] [EMAIL PROTECTED] Yes, it is quite complicated. You can only return variables by reference, a function's return value is not something we can 'connect' to... [2003-07-17 03:35:38] [EMAIL PROTECTED] If you do it like this it works: class TextSanitizer { function &htmlSpecialChars($text) { $foo = preg_replace("/&/i", '&', htmlspecialchars($text, ENT_QUOTES)); return $foo; } } So would it really be *that* hard to make it work? [2003-07-17 03:23:15] [EMAIL PROTECTED] It never really worked (caused memory corruption). Unlikely to be changed, since it doesn't make sense, but we'll see. 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/24687 -- Edit this bug report at http://bugs.php.net/?id=24687&edit=1
#15209 [Com]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209 Comment by: kailash at sarksoft dot com Reported By: priebe at mi-corporation dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: RH Linux 7.3 PHP Version: 4.1.x-4.3.0 New Comment: There is a bug for register_shutdown_function httpd-2.0.40-21 and php-4.2.2-17 under redhat 9.0 It seems to be working fine with php-4.3 and apache 1.3 under suse 8.2 Previous Comments: [2003-02-24 02:53:46] [EMAIL PROTECTED] Closing as bogus. If we ever support this kind of behavior, it won't be a part of register_shutdown_function(). If there was a working patch for apache_register_shutdown_function(), I missed it - please resend. [2002-12-30 11:26:27] [EMAIL PROTECTED] The functionality for register_shutdown_function under 4.0.x will be replaced with a function named apache_register_shutdown_function. This should be available under 4.3.1 and later versions of PHP. I will close this bug when the patch has been committed. [2002-12-27 10:52:01] [EMAIL PROTECTED] I created a patch to add this functionality back under mod_php4 systems. This patch was posted to the php-dev list yesterday. Check out the list archives. An improved patch will be posted later today. [2002-12-23 11:25:38] brianm-php at dealnews dot com The following script will cause IE to stop loading the page when zlib.output_compression is used. This was not true before the changes to register_shutdown_function as the output was not sent. You can see a test at http://dealnews.com/zlibshutdown.php. Mozilla gracefully handles the mixed output by truncating the non-compressed data. This is in the HTML body. [2002-12-12 11:37:31] [EMAIL PROTECTED] I gave up on my patch. Too much work, not enought time, and ultimately, I couldn't find a place in PHP land where PHP was still running and Apache had closed the connection to put my hooks in. There may be a way to tell Apache to close the connection through SAPI, but I am not aware of it. (I'm not an apache hacker). Someone posted a way to fork a process to the background, but it isn't a PHP land solution. >From Carsten Gehling: Maybe this is what you need? http://www.naken.cc/mikehup.php I use this on a CMS site, where the users upload imagefiles with ftp. After that, they use a php webinterface to start an importscript (written in Perl). By doing this command in php: system("/usr/local/bin/mikehup /usr/bin/perl /www/servers/netlag/cronscripts/import_billede.pl &"); The importscript is started and executes in the background while the php-script finishes execution. Hope that helps - Carsten The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15209 -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#18670 [Com]: strtotime() bug
ID: 18670 Comment by: sergio at wgo dot com dot br Reported By: nic at bbmcarlson dot com Status: Open Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.3RC5-dev New Comment: I have a problem to use StrToTime with the date 2003-10-12. Its return -1. I'm using the version PHP 4.3.2 "; Echo Date( 'd-m-Y', StrToTime( $data11 ) ).""; Echo StrToTime( $data11 ).""; Echo Date( 'd-m-Y', StrToTime( $data20 ) )." ** on my server, display '31-12-1969'...BUG or What ? "; Echo Date( 'd-m-Y', StrToTime( $data21 ) )." ** on my server, display '31-12-1969'...BUG or What ? "; Echo StrToTime( $data21 )." display -1 "; Echo Date( 'd-m-Y', StrToTime( $data30 ) ).""; Echo Date( 'd-m-Y', StrToTime( $data31 ) ).""; Echo StrToTime( $data31 ).""; ?> Previous Comments: [2003-02-11 14:12:37] mphillips at lufkin dot org I have noticed that when you do something like $sdate = date9'Y-m-d', strtotime('02-09-2003')); $sdate is getting '2008-02-24'. Is this a common occurance [2002-10-31 12:07:20] matt at codewalkers dot com I also can confirm that strtotime acts funny when the same day does not exist in the next month: displays: December [2002-09-24 17:07:42] spud at nothingness dot org In PHP 4.2.3, the difference between "2" and "next" are still screwy in strtotime(). I'm trying to parse icalendar recurrence formats, so I need to calculate things like the "second Monday" in a month. Sample code below illustrates the difference between "2" and "next" (which should be identical). '); echo ('Start date: Sunday, Sep 1 2002'); $first = strtotime('first Monday',$start); echo ('"First" Monday: '.date('l, M d Y',$first).''); $oneth = strtotime('1 Monday',$start); echo ('"1" Monday: '.date('l, M d Y',$oneth).''); $next = strtotime('next Monday',$start); echo ('"Next" Monday: '.date('l, M d Y',$next).''); $twoth = strtotime('2 Monday',$start); echo ('"2" Monday: '.date('l, M d Y',$twoth).''); $third = strtotime('third Monday',$start); echo ('"Third" Monday: '.date('l, M d Y',$third).''); $threeth = strtotime('3 Monday',$start); echo ('"3" Monday: '.date('l, M d Y',$threeth).''); ?> [2002-07-31 18:07:05] [EMAIL PROTECTED] Assigning to rasmus as it sounds like he already knows whats wrong. [2002-07-31 10:51:09] [EMAIL PROTECTED] so can we assign this bug to you Rasmus? 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/18670 -- Edit this bug report at http://bugs.php.net/?id=18670&edit=1
#25852 [Csd->Bgs]: gmstrftime - the %T option didn't woks
ID: 25852 Updated by: [EMAIL PROTECTED] Reported By: willertan1980 at yahoo dot com -Status: Closed +Status: Bogus Bug Type: Date/time related Operating System: WinXP sp1 PHP Version: 4.3.3 New Comment: That's why the status was set to "bogus" :) Please leave it on this. Previous Comments: [2003-10-14 05:51:03] willertan1980 at yahoo dot com thank , now i knew it. may i know how to delete this false report?. i think it is useless to make this bug report [2003-10-13 19:15:40] [EMAIL PROTECTED] RTFM: "Note: Not all conversion specifiers may be supported by your C library, in which case they will not be supported by PHP's strftime()...e.g. %e, %T, %R and %D (there might be more) and dates prior to Jan 1, 1970 will not work on Windows" [2003-10-13 13:09:51] willertan1980 at yahoo dot com Description: im not sure , this is a bug or not. Im WinXP user, works on IIS with PHP 4.3.3 and i found that echo gmstrftime('%Y %b %d %T '); will out put 2003 Oct 13 and echo gmstrftime('%Y %b %d %H:%M:%S'); the output is 2003 Oct 13 16:20:03 the %T is missing... %T - current time, equal to %H:%M:%S this also happen to strftime -- Edit this bug report at http://bugs.php.net/?id=25852&edit=1
#25859 [Opn->Bgs]: php.exe consumes 100% cpu
ID: 25859 Updated by: [EMAIL PROTECTED] Reported By: mfelden at gsd-web dot de -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: windows 2000 server PHP Version: 4.3.2 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 I'm assuming the select query gets a lot of data: since dbx_query retrieves and buffers all data this could lead to a very long execution time. If this is not the case, please re-open this bug report. Otherwise, read on: First: alter your sql statement to only retrieve fields you actually need, such as 'field' and 'id'. Don't use * in a select statement. Second: your query() function is not very efficient: it would be much better to put the dbx_connect() and dbx_close() calls outside the function, preferably at the beginning and end of the script or perhaps the get_data() function. And when you do that you might as well skip the query() function definition altogether :-) If you are retrieving a lot of records, the new version of dbx_query() (in CVS only) has support for the DBX_RESULT_UNBUFFERED flag where you can retrieve data record by record, which is probably what you want as it is a lot more efficient. If you are unable to get the CVS version, perhaps you should use the mysql_unbuffered_query() directly... Previous Comments: [2003-10-14 06:00:28] mfelden at gsd-web dot de Description: PHP is running on the local http-server IIS. A script loaded in IE 5 causes a new instance of php.exe running on the server. It instantly consumes 100% of the cpu power. This blocks the server, so the query could not be completed. The IIS sends a Timeout after 30 seconds. I can't change it, due to the MMC which says, there is no IIS. Even after closing the IE-Window php.exe is consuming 100% of the cpu power for the next say 5 minutes. During this php.exe dis- and appears in the process list again and again. In php.ini php_iisfunc.dll is commented out. It is no fun. Reproduce code: --- Import Daten holen 590 and id<691"; $result = query($query, $source); for($i = 0; $i < $result->rows; $i++) { $query = "UPDATE corpus SET strasse ='" . $result->data[$i]['field'] . "' WHERE id = " . $result->data[$i]['id']; query($query); } } } function query($query) { $link = dbx_connect (DBX_MSSQL, "1.2.3.4", "db", "user", "pwd", DBX_PERSISTENT| DBX_RESULT_INFO) or die ("Fehler beim Verbinden"); $result = dbx_query($link, $query); dbx_close ($link); return $result; } ?> Expected result: Query completed Actual result: -- Timeout after 30 sec -- Edit this bug report at http://bugs.php.net/?id=25859&edit=1
#25859 [NEW]: php.exe consumes 100% cpu
From: mfelden at gsd-web dot de Operating system: windows 2000 server PHP version: 4.3.2 PHP Bug Type: *General Issues Bug description: php.exe consumes 100% cpu Description: PHP is running on the local http-server IIS. A script loaded in IE 5 causes a new instance of php.exe running on the server. It instantly consumes 100% of the cpu power. This blocks the server, so the query could not be completed. The IIS sends a Timeout after 30 seconds. I can't change it, due to the MMC which says, there is no IIS. Even after closing the IE-Window php.exe is consuming 100% of the cpu power for the next say 5 minutes. During this php.exe dis- and appears in the process list again and again. In php.ini php_iisfunc.dll is commented out. It is no fun. Reproduce code: --- Import Daten holen 590 and id<691"; $result = query($query, $source); for($i = 0; $i < $result->rows; $i++) { $query = "UPDATE corpus SET strasse ='" . $result->data[$i]['field'] . "' WHERE id = " . $result->data[$i]['id']; query($query); } } } function query($query) { $link = dbx_connect (DBX_MSSQL, "1.2.3.4", "db", "user", "pwd", DBX_PERSISTENT| DBX_RESULT_INFO) or die ("Fehler beim Verbinden"); $result = dbx_query($link, $query); dbx_close ($link); return $result; } ?> Expected result: Query completed Actual result: -- Timeout after 30 sec -- Edit bug report at http://bugs.php.net/?id=25859&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25859&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25859&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25859&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25859&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25859&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25859&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25859&r=support Expected behavior: http://bugs.php.net/fix.php?id=25859&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25859&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25859&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25859&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25859&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25859&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25859&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25859&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25859&r=float
#25852 [Bgs->Csd]: gmstrftime - the %T option didn't woks
ID: 25852 User updated by: willertan1980 at yahoo dot com Reported By: willertan1980 at yahoo dot com -Status: Bogus +Status: Closed Bug Type: Date/time related Operating System: WinXP sp1 PHP Version: 4.3.3 New Comment: thank , now i knew it. may i know how to delete this false report?. i think it is useless to make this bug report Previous Comments: [2003-10-13 19:15:40] [EMAIL PROTECTED] RTFM: "Note: Not all conversion specifiers may be supported by your C library, in which case they will not be supported by PHP's strftime()...e.g. %e, %T, %R and %D (there might be more) and dates prior to Jan 1, 1970 will not work on Windows" [2003-10-13 13:09:51] willertan1980 at yahoo dot com Description: im not sure , this is a bug or not. Im WinXP user, works on IIS with PHP 4.3.3 and i found that echo gmstrftime('%Y %b %d %T '); will out put 2003 Oct 13 and echo gmstrftime('%Y %b %d %H:%M:%S'); the output is 2003 Oct 13 16:20:03 the %T is missing... %T - current time, equal to %H:%M:%S this also happen to strftime -- Edit this bug report at http://bugs.php.net/?id=25852&edit=1
#25850 [Com]: SWITCH
ID: 25850 Comment by: tony2001 at phpclub dot net Reported By: jakespotgieter at hotmail dot com Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Windows PHP Version: 5CVS-2003-10-13 (dev) New Comment: I can't find any bug here. Passing to the script "?method=Bar" in query string and having $i equal to true it works well under PHP5-CVS. If you get any errors here - copy/paste it and wrote a letter to [EMAIL PROTECTED] Previous Comments: [2003-10-13 11:58:41] [EMAIL PROTECTED] The syntax of the header() call is wrong too. [2003-10-13 08:23:02] jakespotgieter at hotmail dot com Sorry, I wrote this code quickly, trust me its got nothing to do with a parse error. It doesnt work on the Zend engine 2. I ported it back to 4.3, and it worked. I didnt change anything in the code. SWITCH ($_GET['method']){ CASE 'Foo': //do something BREAK; CASE 'Bar': if($i == true){ header("location:?method=Foo"); }else{ //do something else } BREAK; } [2003-10-13 07:55:12] [EMAIL PROTECTED] Not a bug, but wrong syntax. [2003-10-13 07:42:27] [EMAIL PROTECTED] There is parse error in your code: you forgot to add semicolon at the end of line with Header(). This code cannot be parsed correctly neither under PHP5CVS, nor PHP4.3.3. Having this error fixed, code works ok (but complies on undefined variables). So, this is problem of your code. [2003-10-13 07:25:43] jakespotgieter at hotmail dot com Description: When there are multiple cases within a switch block, if you try to use the header function, more specifically header("location:$url") it doesn't work. When I ran the same code under 4.3.3 it worked. Reproduce code: --- SWITCH ($_GET['method']){ CASE 'Foo': //do something BREAK; CASE 'Bar': if($i == true){ header("location:?method=Foo") }else{ //do something else } BREAK; } -- Edit this bug report at http://bugs.php.net/?id=25850&edit=1
#22459 [Com]: Fatal error: session_start() [function.session-start]
ID: 22459 Comment by: mikael at chl dot chalmers dot se Reported By: froeschlin at designpark dot de Status: Bogus Bug Type: Session related Operating System: Red-Hat/Linux PHP Version: 4.3.3 New Comment: Have the same problem, tried using both files and mm for storage handler, changing all the session settings etc. Have had the problem through php4.3.2 -> 4.3.4RC1 with the same results, php randomly outputting these errors on perhaps every 1/4 of the session inits. config: http://www.geckominus.com/phpinfo.php Previous Comments: [2003-08-28 19:40:48] [EMAIL PROTECTED] That url says 'PHP 4.2.2', please upgrade to 4.3.3 first. [2003-02-27 09:48:18] froeschlin at designpark dot de We have remove the Optimizer but after 2-3 hours the error come again. [2003-02-27 08:48:57] [EMAIL PROTECTED] Turn off Zend Optimizer v2.1.0 and see if the problem persists. [2003-02-27 08:33:48] froeschlin at designpark dot de When we use session_start() we get a random coming error on our system who give us out the folloing massage: Fatal error: session_start() [function.session-start]: Failed to initialize session module Sometimes the error dont come over days. We cant recognize why and how it develops. Also the compiling of php are error less. Our config -> http://217.175.242.77/phpinfo.php -- Edit this bug report at http://bugs.php.net/?id=22459&edit=1
#21676 [Com]: GetImageSize nolonger works
ID: 21676 Comment by: hex6ng at yahoo dot com Reported By: moderator at blackpeeps dot com Status: Closed Bug Type: GetImageSize related Operating System: RAQ4-Latest Patches/Apache 1.3.2 PHP Version: 4.3.0 New Comment: I'm experiencing the same problem after I upgraded php from version 4.2.4-CVS (php4-STABLE-20030230) to 4.3.3 Release. The reason I upgraded was because 4.3.3 fixes the PATH_INFO bug that I had. But..A whole bunch of my thumbnails stopped showing up. The really odd thing is I'm using Imagick instead of GD. But I'm also using getimagesize(). I changed my function to use ALL three methods of retrieving the size, but ALL return null size for these images. http://filegrid.net/index.html?meta_id=5ca930302a942ef8906a6a80855856af here is the function I use to get the size function file_image_size($meta_id) { $file_obj = file_object($meta_id); if(!$file_obj) return NULL; $image_size = getimagesize($file_obj->file_location); if(!$image_size[0]) { if(!$image_size[0]) { $handle = imagick_readimage($file_obj->file_location); if(imagick_iserror( $handle )) return NULL; $image_size[0] = imagick_getwidth($handle); $image_size[1] = imagick_getheight($handle); //imagick_free($handle); if(!$image_size[0] && stristr($file_obj->mime_type, 'image/jp')) { $img = imagecreatefromjpeg ($filename); $image_size[0] = imagesx ($img); $image_size[1] = imagesy ($img); imagedestroy ($img); } } } return $image_size; } Previous Comments: [2003-05-12 03:07:57] fmeriot at hotmail dot com I'have experienced the same problem with the getimagesize() function. I use it to test the size of a distant image to display on my site. If width is greater than 500 pix I force the width parameter to 500. This function works with some images but not with all. Example: It works with this one: http://images.ea.com/eagames/official/bf1942/screenshots_rome/full_screen_21.jpg It doesn't work with this one: http://www.dayofdefeatmod.com/media/images/Jagd1.jpg I have no error message. When I do that: $size = @getimagesize("http://www.dayofdefeatmod.com/media/images/Jagd1.jpg";); echo $size[0]; Nothing happens, nothing appears. [2003-04-29 16:10:24] michael dot mauch at gmx dot de So you have two options: a) Wait until PHP 4.3.2 is released and installed at your site. b) Invent a time travel machine and give it to the PHP developers, so PHP 4.3.0 can be fixed before it was installed at your site. [2003-04-29 09:23:20] ruud at webhero dot nl It still doesn't work. My site still does have problems with @Getimagesize example: http://www.gamemag.nl/nieuws/item.php?id=2109 You see three screens, the fourth doesn't work. All images are from an external website and use the same functions. I don't have permission to change my PHPversion. Please help, Rudy Luiten [2003-02-22 05:19:09] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. This one has been fixed by fixing a streams issue. [2003-01-31 13:52:04] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. 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/21676 -- Edit this bug report at http://bugs.php.net/?id=21676&edit=1