#32886 [NEW]: Session dont store the correct values
From: luis at infomed dot sld dot cu Operating system: Linux & Windows PHP version: 5.0.4 PHP Bug Type: Session related Bug description: Session dont store the correct values Description: php5.0.4 dont store the correct values after modified the $_SESSION variable, the idea is to clear the session and do persist only a few values. I use Apache 1.3.33. With php5.0.2 everything is fine the problem appear with php5.0.4, I am not try with php5.0.3 Reproduce code: --- page1.php- page2.php- page2b.php- page3.php- Expected result: I would expect the same behavior with: page1.php->page2.php->page3.php and with: page1.php->page2b.php->page3.php but is not. Actual result: -- When I do page1.php->page2.php on the screen I obtain the correct values: Array ( [varA] => aaa ) but on the session file in disc is wrong, because the session file have: varA|s:3:"aaa";varB|s:3:"bbb"; and in page3.php on the screen I have: Array ( [varA] => aaa [varB] => bbb ), is wrong. But, if I do page1.php->page2b.php->page3.php everything is fine. Thank you for your work in PHP. -- Edit bug report at http://bugs.php.net/?id=32886&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32886&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32886&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32886&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32886&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32886&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32886&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32886&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32886&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32886&r=support Expected behavior: http://bugs.php.net/fix.php?id=32886&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32886&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32886&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32886&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32886&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32886&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32886&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32886&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32886&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32886&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32886&r=mysqlcfg
#32885 [NEW]: Miscalulcating string length
From: homework at aofrozencity dot com Operating system: Windows 2003 Server PHP version: 4.3.9 PHP Bug Type: Strings related Bug description: Miscalulcating string length Description: 'pictures' should be 8 string length. Thought, I got the result. It said that 'pictures' is 13 string length. It isn't correct. I notice that I use different words. It shows that string length is added with 5 practically. You can see that 8 (pcitures) length + 5 add length = 13 string length. I don't know why it is. Reproduce code: --- function word_match($a=null,$b=null) { print("Orginal A: $a"); $a_length = strlen($a); $b_length = strlen($b); $search = true; $length = 0; while($search) { if(substr($b,$length,$a_length)==$a) { $search = false; $result = true; }elseif($length>$b_length){ print("Websatellite: A: $a B: $b ($length>$b_length)"); $result = false; $search = false; } print("Websatellite: ($a_length) ".substr($b,$length,$a_length)."==$a"); $length++; } return $result; } -- Edit bug report at http://bugs.php.net/?id=32885&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32885&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32885&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32885&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32885&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32885&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32885&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32885&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32885&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32885&r=support Expected behavior: http://bugs.php.net/fix.php?id=32885&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32885&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32885&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32885&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32885&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32885&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32885&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32885&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32885&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32885&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32885&r=mysqlcfg
#32854 [Opn->Asn]: mssql_pconnect fails under load and doesn't recover
ID: 32854 Updated by: [EMAIL PROTECTED] Reported By: gerritgiliomee at hotmail dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: Windows 2000 sp4 PHP Version: 5.0.4 -Assigned To: +Assigned To: fmk Previous Comments: [2005-04-27 13:09:17] gerritgiliomee at hotmail dot com Description: Using mssql_pconnect to connect to a MS SQL2000 server on another box. Everything works a treat until I put some load on. When I go above a certain threshhold, e.g. using Apache Benchmark, 20 concurrent users, 500 requests, mssql_pconnect fails with this error: "Warning: mssql_pconnect() [function.mssql-pconnect]: Unable to connect to server: servername" This is understandable as things will break above a certain point, however, after this happens, mssql_pconnect seems to have hung, even if I change the connection details, or try using mssql_connect, I still get the same error. The only thing that resolves it is restarting IIS. Using Win2K (sp4), IIS5, MS SQL 200 (sp2). PS: I have made sure I'm using the right version of ntwdblib.dll. It's also worth noting that my phpinfo() reports "Library Version: 7.0" instead of the presumed 8.0. Not sure if this is connected to the SQL version though. I've toggled around and have these mssql settings in my php.ini [MSSQL] ; Allow or prevent persistent links. mssql.allow_persistent = On ; Maximum number of persistent links. -1 means no limit. mssql.max_persistent = 100 ; Maximum number of links (persistent+non persistent). -1 means no limit. mssql.max_links = 100 ; Minimum error severity to display. mssql.min_error_severity = 10 ; Minimum message severity to display. mssql.min_message_severity = 10 ; Compatability mode with old versions of PHP 3.0. mssql.compatability_mode = Off ; Connect timeout mssql.connect_timeout = 5 ; Query timeout mssql.timeout = 60 ; Valid range 0 - 2147483647. Default = 4096. mssql.textlimit = 4096 ; Valid range 0 - 2147483647. Default = 4096. mssql.textsize = 4096 ; Limits the number of records in each batch. 0 = all records in one batch. mssql.batchsize = 0 ; Specify how datetime and datetim4 columns are returned ; On => Returns data converted to SQL server settings ; Off => Returns values as -MM-DD hh:mm:ss ;DEV - used to be completely commented out mssql.datetimeconvert = Off ; Use NT authentication when connecting to the server mssql.secure_connection = Off ; Specify max number of processes. Default = 25 mssql.max_procs = 25 Any help will be much appreciated. -- Edit this bug report at http://bugs.php.net/?id=32854&edit=1
#32883 [NEW]: Last character truncated from each line of post-moved file
From: jack at martinelli dot org Operating system: Linux (Debian) PHP version: 4.3.10 PHP Bug Type: Filesystem function related Bug description: Last character truncated from each line of post-moved file Description: On Windows upload a text file, e.g., 123 456 789 Then on the server move the uploaded file to some directory then dump the file & its: 12 45 78 Reproduce code: --- move_uploaded_file( $_FILES[$filename],['tmp_name'], 'tmp/tmp.txt'); echo file_get_contents ('tmp/tmp.txt'); Expected result: 123 456 789 Actual result: -- 12 45 78 -- Edit bug report at http://bugs.php.net/?id=32883&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32883&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32883&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32883&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32883&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32883&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32883&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32883&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32883&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32883&r=support Expected behavior: http://bugs.php.net/fix.php?id=32883&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32883&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32883&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32883&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32883&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32883&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32883&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32883&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32883&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32883&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32883&r=mysqlcfg
#31222 [Fbk->Opn]: ocicommit not working
ID: 31222 User updated by: amonw at hotmail dot com Reported By: amonw at hotmail dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: Thank you for your suggestion. But I'm not ready to upgrade my system to php5 because I don't have much time to modify the old codes to fit in php5 yet. Previous Comments: [2005-04-28 12:56:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-04-26 04:20:18] amonw at hotmail dot com I don't know why, but I upgrate my php again this morning to php4-stable-200504260035, and the problem remains unchanged. I have make the code as simple as possible, and as I mentioned in the first comment, even some minor changes which seem not relevant may affect the result, and I don't know why. I deeply appreciate your patiense and please read my first post again. I can live with it if you are tired of this because it takes so long. Thank you. [2005-04-05 17:55:52] [EMAIL PROTECTED] Works just perfectly for all of oci8 users except you. Try to simplify the code and to look for the problem there. [2005-04-04 09:27:40] amonw at hotmail dot com I tried the http://snaps.php.net/php4-STABLE-latest.tar.gz,which extracted to be php4-STABLE-200504040230,but the code produced the same result. [2005-03-30 23:06:56] [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 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222&edit=1
#31774 [Opn->Asn]: Data missing using DirectoryIterator with ftp:// wrapper
ID: 31774 Updated by: [EMAIL PROTECTED] Reported By: php at lachoseinteractive dot net -Status: Open +Status: Assigned Bug Type: FTP related Operating System: Linux & Mac OS X PHP Version: 5CVS-2005-03-20 -Assigned To: +Assigned To: pollita New Comment: Assigned to the FTP maintainer.. :) Previous Comments: [2005-03-22 20:33:11] php at lachoseinteractive dot net Same bug in php5-200503201530 [2005-02-28 20:53:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-01-31 12:41:10] php at lachoseinteractive dot net After more investigation, it turns out that the iterator reconnects to the server several times for each file of list in order to get SIZE information, etc instead of parsing a raw list from an FTP LIST command. Looks like DirectoryIterator needs optimization for use with ftp wrapper. [2005-01-31 02:32:17] php at lachoseinteractive dot net Description: Reading a directory with a DirectoryIterator using an ftp wrapper doesn't work well. Tested on 3 ftp servers. (proftp, ncftp, and ..unknown :-/). on 3 different machines and network. With proftp and ncftp, some items are missing from the retrieved directory list. (whereas it works well with readdir()), even with a directory containing no more than 2 or 3 files. This doesn't seem to be related to the nature of the file, but rather to its position in the list : add a new file to the directory, and the previously missing file would show up, while another one is now missing. On the third server (ftpperso.free.fr), the directory was correctly read. In all cases, retrieving the list is very slow, and often fails. Reproduce code: --- example: $dir = new DirectoryIterator("ftp://myftpserver.com/";); foreach ( $dir as $f ) { if ( $f->isDot() ) continue; echo $f->getFilename()."\n"; } -- Edit this bug report at http://bugs.php.net/?id=31774&edit=1
#31525 [Opn->Asn]: object reference being dropped. $this getting lost.
ID: 31525 Updated by: [EMAIL PROTECTED] Reported By: yml at yml dot com -Status: Open +Status: Assigned Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-03 -Assigned To: +Assigned To: andi New Comment: Andi, I think you once responded to similar issue regarding return() with/without parenthesis.. Previous Comments: [2005-03-06 05:55:37] yml at yml dot com Problem found. Removing all the ()'s from reference returning functions and the problem has completely disappeared. However, the case should be caught by the parser and a warning generated. Using parens around returns returning references will cause symbol table corruption occassionally ... [2005-03-06 02:43:51] michaels at crye-leike dot com True, if getThis() is declared to return a reference then everything works as expected. However, looking through the original reproduce code I noticed something else. If you add parentheses around $this in getThis() then the unexpected behavior returns. Complete code: getThis(); } } $bar = new Foo(); $bar->destroyThis(); var_dump($bar); ?> Produces: NULL Expected: object(Foo)#1 (0) { } [2005-03-06 01:50:27] yml at yml dot com Unfortunately the shortened script works as it should if you declare getThis to return a reference as in function &getThis() If however, you refer to the "too-long" script I put together at: http://www.formvista.com/uploaded_files/php5_drops_object.php.txt There is something different about it that causes $this to get dropped even when the method is declared return-by-reference. I haven't been able to narrow it down but it's entirely possible I'm overlooking something obvious. It's got to be something related to legacy pass by reference notation =&. The strange thing is it worked in 5.0.1 and broke in 5.0.2 or .3. [2005-03-06 01:26:05] michaels at crye-leike dot com FWIW, here's a shorter script that reproduces the problem for me on PHP 5.0.3: getThis(); } } $bar = new Foo(); $bar->destroyThis(); var_dump($bar); ?> This outputs: NULL If I change the assign-by-reference operator (=&) to the normal assignment operator (=) inside destroyThis(), I get: object(Foo)#1 (0) { } Hope this helps... [2005-03-03 18:32:24] yml at yml dot com 1. Same problem. No improvement. $this is getting dropped. Used to work in 5.0RC2. Since 5.0.3 it's been broken. 2. The script I sent was puny. Given how terribly buggy the Zend engine is, expecting that all serious parser errors can be reproduced in a total of 20 lines or less is ridiculous. The meat of the script I sent clearly reproduces the problem in 8 lines, not including the supporting classes. You guys wouldn't pull it from my site; and now you won't look at it if I send it to you. Exactly what would you propose I do to help you track this down? The 85,000 lines of code that's actually having this problem (and producing a coredump), now that's a huge "script". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31525 -- Edit this bug report at http://bugs.php.net/?id=31525&edit=1
#30525 [Opn->Bgs]: mysql_close() fails in some situations with shared links
ID: 30525 Updated by: [EMAIL PROTECTED] Reported By: l dot cameron2 at ugrad dot unimelb dot edu dot au -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: * PHP Version: 5.0.x and 4.x New Comment: Please stop reopening this, this is not a bug but just how it works. Previous Comments: [2005-04-29 01:56:54] l dot cameron2 at ugrad dot unimelb dot edu dot au Please reread the first post where I explicitly talked about shared connection behaviour. The bug is that when using shared connections, if you ever use mysql_close() *and* set your links to null, your shared connections will be closed prematurely. As outlined above, the net result of the is that you can never call mysql_close() on a shared connection and expect to have it work correctly. [2005-04-27 14:48:13] [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 When using same connection parameters no new connection will be established by default, instead an exisiting one will be reused. Set the optional newlink parameter to true if you want to establish more than one physical connection. [2005-04-27 13:25:23] kevin at hatry dot com i just want to add a last comment to make clear that this bug is important. this is (i think) a much used type of program : fails with : link1:resource(4) of type (mysql link) link3:resource(4) of type (mysql link) Warning: mysql_close(): 4 is not a valid MySQL-Link resource in ... on line 14 link1:resource(4) of type (Unknown) i think that closing a connection in the same environnement that it was open (like in the function here) is good programming so it shouldn't fail like that ! And the problem is *not* that the mysql_close closed all connections as shown by this example : here there is no failure : link1:resource(4) of type (mysql link) link2:resource(4) of type (mysql link) link3:resource(4) of type (mysql link) link1:resource(4) of type (Unknown) link2:resource(4) of type (Unknown) there would be one if we had closed $link2 after $link1 for example. [2004-10-22 06:19:48] l dot cameron2 at ugrad dot unimelb dot edu dot au Description: Preface: I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links; see #9107: there now there appears to be reference counting before finally closing the TCP connection -- which is IMHO better than the older behaviour, but the implementation has its own bugs: PHP appears to keeps an internal count of the number of times a link has been duplicated. When the link count is <= 0, the underlying TCP connection is actually closed. * close() reduces the link count by 1 * setting the connection to null *also* reduces the link count by 1 -- even if that link has already been close()d Currently the only workarounds for this are to: [1] Set new_link to true every time you mysql_connect() -- potentially creating a lot of TCP connections and slowing the program down [2] close() the link, but never set it to null and hope that PHP won't clean it up until the end of the program: This *will* fail sometimes though; see the example at http://www.levi.id.au/mysql4.php.txt [3] Never mysql_close() links, only set them to null and hope that PHP will in fact clean up the TCP connection before MySQL runs out of available connections (admittedly only a problem when you have a lot of simultaneous connections to your database) -- this does work now, but we're not supposed to assume anything about when PHP does its object destruction. The third is really the only viable solution; but is dependent on the internal implementation of the MySQL extension. At best, the current situation is that if you ever have shared links, you should never call mysql_close if you ever expect to use that database again in your program. Reproduce code: --- Simple example: #!/usr/local/bin/php -q See also the example at http://www.levi.id.au/mysql4.php.txt Expected result: Blank output. Actual result: -- PHP Warning: mysql_close(): 1 is not a valid MySQL-Link resource in /home/levi/public_html/mysql2.php on line 10 Warning: mysql_close(): 1 is not a valid MySQL-Link resource in /home/levi/public_html/mysql2.php on line 10 (If I remove the mysql_close($conn1); it works) (If I remove the $conn1 = null; it also works) -
#29514 [Opn->Csd]: auto_globals_jit not in php.ini
ID: 29514 Updated by: [EMAIL PROTECTED] Reported By: holliwell at gmx dot net -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: linux -2.4.20 PHP Version: 5.0.0 New Comment: Committed. Previous Comments: [2005-04-26 16:28:03] [EMAIL PROTECTED] Docu people doesn't have karma to add it to php.ini, can someone from source code guys do it? [2005-04-11 09:28:04] [EMAIL PROTECTED] A message was sent to php-internals with a patch for php.ini here: * http://marc.theaimsgroup.com/?l=php-dev&m=111204914824598 [2005-02-25 22:31:07] [EMAIL PROTECTED] This is now documented in the PHP Manual but still needs to find its way into php.ini-{dist|recommended) Here's the diff: http://cvs.php.net/diff.php/phpdoc/en/appendices/ini.xml?r1=1.11&r2=1.12&ty=h [2004-08-17 18:06:18] [EMAIL PROTECTED] Changed to docu problem, 'cos it's not documented too. Probably Zeev can tell about Just-In-Time variables initialization, as he was the person who implemented it. [2004-08-03 23:59:30] holliwell at gmx dot net Description: Hi, phpinfo() reports about auto_globals_jit, but this directive is neither in php.ini-dist nor php.ini-recommended. Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=29514&edit=1
#32852 [Opn->Asn]: Crash with singleton and __destruct when zend.ze1_compatibility_mode = On
ID: 32852 Updated by: [EMAIL PROTECTED] -Summary: Crash with singleton and __destruct Reported By: cox at idecnet dot com -Status: Open +Status: Assigned -Bug Type: Reproducible crash +Bug Type: Zend Engine 2 problem -Operating System: Linux +Operating System: * -PHP Version: 5.0.4 +PHP Version: 5CVS-2005-04-29 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, if you have time, can you look into these reports with problems with zend.ze1_compatibility_mode? Some of them happen with only PHP_5_0 and some with both it and HEAD. Here's list (this bug excluded): bug #30332 bug #31828 bug #32080 Previous Comments: [2005-04-28 16:03:57] cox at idecnet dot com Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache && ./configure + your options + --enable-debug && make clean && make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852&edit=1
#32882 [Opn]: Stored Procedure spoils connection
ID: 32882 User updated by: sales at girderboot dot com Reported By: sales at girderboot dot com Status: Open Bug Type: MySQLi related Operating System: Windows Server 2003 PHP Version: 5.0.4 New Comment: Upgraded to latest CVS [5.1.0-dev, Apr 26 2005 04:15:08 ] Still same Problem. Previous Comments: [2005-04-29 02:45:50] sales at girderboot dot com Description: After executing a query using a stored procedure that returns a result set, no futher queries can be executed. SProc's that don't return a result set, or embedded SQL queries are not affected (but even they still cannot run after a SP with a result set is run.) MySQL and PHP both version 5.0.4 Reproduce code: --- $db = new mysqli('localhost','xxx','xxx','campnet'); if (!$exec = $db->query("CALL Acct_Bal(1)")) echo $db->error; $balance = $exec->fetch_row(); $exec->close(); echo $balance[0]; echo ""; // Second Time if (!$exec = $db->query("CALL Acct_Bal(1)")) echo $db->error; $balance = $exec->fetch_row(); $exec->close(); echo $balance[0]; Expected result: Should Output the same result Twice (In this case, the accout balance): 0.00 0.00 Actual result: -- 0.00 Lost connection to MySQL server during query Fatal error: Call to a member function fetch_row() on a non-object in C:\Program Files\Apache Group\Apache2\htdocs\driver.php on line 40 -- Edit this bug report at http://bugs.php.net/?id=32882&edit=1
#32882 [NEW]: Stored Procedure spoils connection
From: sales at girderboot dot com Operating system: Windows Server 2003 PHP version: 5.0.4 PHP Bug Type: MySQLi related Bug description: Stored Procedure spoils connection Description: After executing a query using a stored procedure that returns a result set, no futher queries can be executed. SProc's that don't return a result set, or embedded SQL queries are not affected (but even they still cannot run after a SP with a result set is run.) MySQL and PHP both version 5.0.4 Reproduce code: --- $db = new mysqli('localhost','xxx','xxx','campnet'); if (!$exec = $db->query("CALL Acct_Bal(1)")) echo $db->error; $balance = $exec->fetch_row(); $exec->close(); echo $balance[0]; echo ""; // Second Time if (!$exec = $db->query("CALL Acct_Bal(1)")) echo $db->error; $balance = $exec->fetch_row(); $exec->close(); echo $balance[0]; Expected result: Should Output the same result Twice (In this case, the accout balance): 0.00 0.00 Actual result: -- 0.00 Lost connection to MySQL server during query Fatal error: Call to a member function fetch_row() on a non-object in C:\Program Files\Apache Group\Apache2\htdocs\driver.php on line 40 -- Edit bug report at http://bugs.php.net/?id=32882&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32882&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32882&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32882&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32882&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32882&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32882&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32882&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32882&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32882&r=support Expected behavior: http://bugs.php.net/fix.php?id=32882&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32882&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32882&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32882&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32882&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32882&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32882&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32882&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32882&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32882&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32882&r=mysqlcfg
#32850 [Opn->Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) New Comment: It doesn't crash for me (either, as I guess it didn't for Antony?). So..start with the configure line you used? :) Previous Comments: [2005-04-28 22:46:11] [EMAIL PROTECTED] PHP crashes in the second I invoke ./php Like the backtrace shows it dies when loading sqlite extension because it ends up calling zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) <--- with a 0x0 NULL pointer [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? [2005-04-27 12:04:51] [EMAIL PROTECTED] Description: #0 zend_hash_merge_ex (target=0x82f2d38, source=0x98, pCopyConstructor=0x81d6e10 , size=4, pMergeSource=0x81c8ec0 , pParam=0x0) at /home/.../php5-200504251230/Zend/zend_hash.c:818 p = (Bucket *) 0x82f2ca0 t = (void *) 0x82f4908 #1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) at /home/.../php5-200504251230/Zend/zend_compile.c:2099 No locals. #2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0, num_interfaces=2) at /home/.../php5-200504251230/Zend/zend_API.c:1646 interface_entry = (zend_class_entry *) 0x98 ce_num = 2 impl_num = 2 interface_list = 0xb390 "è#@ ¦/@\214" #3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at /home/.../php5-200504251230/ext/sqlite/sqlite.c:1024 No locals. #4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at /home/.../php5-200504251230/Zend/zend_API.c:1227 lcname = 0x0 module_ptr = (zend_module_entry *) 0x82f0028 #5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at /home/.../php5-200504251230/main/main.c:1269 end = (zend_module_entry **) 0x82a453c #6 0x08246d2b in php_startup_internal_extensions () at main/internal_functions_cli.c:72 No locals. #7 0x081a13ea in php_module_startup (sf=0x828396c, additional_modules=0x0, num_additional_modules=152) at /home/.../php5-200504251230/main/main.c:1454 zuf = {error_function = 0x819fbb0 , printf_function = 0x819f510 , write_function = 0x81a0d70 , fopen_function = 0x81a0220 , message_handler = 0x81a0340 , block_interruptions = 0, unblock_interruptions = 0, get_configuration_directive = 0x81a02f0 , ticks_function = 0x81abd60 , on_timeout = 0x81a0480 , stream_open_function = 0x81a0270 , vspprintf_function = 0x81a42c0 , getenv_function = 0x81a7620 } zuv = {import_use_extension = 0x82576e6 ".php", import_use_extension_length = 136766146, html_errors = 1 '\001'} #8 0x08245c9e in main (argc=1, argv=0xbbd4) at /home/.../php5-200504251230/sapi/cli/php_cli.c:632 exit_status = 0 c = 152 file_handle = {type = 0 '\0', filename = 0x82a46f4 "[EMAIL PROTECTED]", opened_path = 0xbb28 "Hûÿ¿Ûs$\bÜûÿ¿`\234/@", handle = {fd = 134697609, fp = 0x8075289, stream = {handle = 0x8075289, reader = 0x402f9c50 , closer = 0xbb34, interactive = -1073743032}}, free_filename = 219 'Û'} -- Edit this bug report at http://bugs.php.net/?id=32850&edit=1
#32850 [Fbk->Opn]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) Previous Comments: [2005-04-28 22:46:11] [EMAIL PROTECTED] PHP crashes in the second I invoke ./php Like the backtrace shows it dies when loading sqlite extension because it ends up calling zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) <--- with a 0x0 NULL pointer [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? [2005-04-27 12:04:51] [EMAIL PROTECTED] Description: #0 zend_hash_merge_ex (target=0x82f2d38, source=0x98, pCopyConstructor=0x81d6e10 , size=4, pMergeSource=0x81c8ec0 , pParam=0x0) at /home/.../php5-200504251230/Zend/zend_hash.c:818 p = (Bucket *) 0x82f2ca0 t = (void *) 0x82f4908 #1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) at /home/.../php5-200504251230/Zend/zend_compile.c:2099 No locals. #2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0, num_interfaces=2) at /home/.../php5-200504251230/Zend/zend_API.c:1646 interface_entry = (zend_class_entry *) 0x98 ce_num = 2 impl_num = 2 interface_list = 0xb390 "è#@ ¦/@\214" #3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at /home/.../php5-200504251230/ext/sqlite/sqlite.c:1024 No locals. #4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at /home/.../php5-200504251230/Zend/zend_API.c:1227 lcname = 0x0 module_ptr = (zend_module_entry *) 0x82f0028 #5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at /home/.../php5-200504251230/main/main.c:1269 end = (zend_module_entry **) 0x82a453c #6 0x08246d2b in php_startup_internal_extensions () at main/internal_functions_cli.c:72 No locals. #7 0x081a13ea in php_module_startup (sf=0x828396c, additional_modules=0x0, num_additional_modules=152) at /home/.../php5-200504251230/main/main.c:1454 zuf = {error_function = 0x819fbb0 , printf_function = 0x819f510 , write_function = 0x81a0d70 , fopen_function = 0x81a0220 , message_handler = 0x81a0340 , block_interruptions = 0, unblock_interruptions = 0, get_configuration_directive = 0x81a02f0 , ticks_function = 0x81abd60 , on_timeout = 0x81a0480 , stream_open_function = 0x81a0270 , vspprintf_function = 0x81a42c0 , getenv_function = 0x81a7620 } zuv = {import_use_extension = 0x82576e6 ".php", import_use_extension_length = 136766146, html_errors = 1 '\001'} #8 0x08245c9e in main (argc=1, argv=0xbbd4) at /home/.../php5-200504251230/sapi/cli/php_cli.c:632 exit_status = 0 c = 152 file_handle = {type = 0 '\0', filename = 0x82a46f4 "[EMAIL PROTECTED]", opened_path = 0xbb28 "Hûÿ¿Ûs$\bÜûÿ¿`\234/@", handle = {fd = 134697609, fp = 0x8075289, stream = {handle = 0x8075289, reader = 0x402f9c50 , closer = 0xbb34, interactive = -1073743032}}, free_filename = 219 'Û'} -- Edit this bug report at http://bugs.php.net/?id=32850&edit=1
#30525 [Bgs->Opn]: mysql_close() fails in some situations with shared links
ID: 30525 User updated by: l dot cameron2 at ugrad dot unimelb dot edu dot au Reported By: l dot cameron2 at ugrad dot unimelb dot edu dot au -Status: Bogus +Status: Open Bug Type: MySQL related -Operating System: win32 +Operating System: * PHP Version: 5.0.x and 4.x New Comment: Please reread the first post where I explicitly talked about shared connection behaviour. The bug is that when using shared connections, if you ever use mysql_close() *and* set your links to null, your shared connections will be closed prematurely. As outlined above, the net result of the is that you can never call mysql_close() on a shared connection and expect to have it work correctly. Previous Comments: [2005-04-27 14:48:13] [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 When using same connection parameters no new connection will be established by default, instead an exisiting one will be reused. Set the optional newlink parameter to true if you want to establish more than one physical connection. [2005-04-27 13:25:23] kevin at hatry dot com i just want to add a last comment to make clear that this bug is important. this is (i think) a much used type of program : fails with : link1:resource(4) of type (mysql link) link3:resource(4) of type (mysql link) Warning: mysql_close(): 4 is not a valid MySQL-Link resource in ... on line 14 link1:resource(4) of type (Unknown) i think that closing a connection in the same environnement that it was open (like in the function here) is good programming so it shouldn't fail like that ! And the problem is *not* that the mysql_close closed all connections as shown by this example : here there is no failure : link1:resource(4) of type (mysql link) link2:resource(4) of type (mysql link) link3:resource(4) of type (mysql link) link1:resource(4) of type (Unknown) link2:resource(4) of type (Unknown) there would be one if we had closed $link2 after $link1 for example. [2004-10-22 06:19:48] l dot cameron2 at ugrad dot unimelb dot edu dot au Description: Preface: I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links; see #9107: there now there appears to be reference counting before finally closing the TCP connection -- which is IMHO better than the older behaviour, but the implementation has its own bugs: PHP appears to keeps an internal count of the number of times a link has been duplicated. When the link count is <= 0, the underlying TCP connection is actually closed. * close() reduces the link count by 1 * setting the connection to null *also* reduces the link count by 1 -- even if that link has already been close()d Currently the only workarounds for this are to: [1] Set new_link to true every time you mysql_connect() -- potentially creating a lot of TCP connections and slowing the program down [2] close() the link, but never set it to null and hope that PHP won't clean it up until the end of the program: This *will* fail sometimes though; see the example at http://www.levi.id.au/mysql4.php.txt [3] Never mysql_close() links, only set them to null and hope that PHP will in fact clean up the TCP connection before MySQL runs out of available connections (admittedly only a problem when you have a lot of simultaneous connections to your database) -- this does work now, but we're not supposed to assume anything about when PHP does its object destruction. The third is really the only viable solution; but is dependent on the internal implementation of the MySQL extension. At best, the current situation is that if you ever have shared links, you should never call mysql_close if you ever expect to use that database again in your program. Reproduce code: --- Simple example: #!/usr/local/bin/php -q See also the example at http://www.levi.id.au/mysql4.php.txt Expected result: Blank output. Actual result: -- PHP Warning: mysql_close(): 1 is not a valid MySQL-Link resource in /home/levi/public_html/mysql2.php on line 10 Warning: mysql_close(): 1 is not a valid MySQL-Link resource in /home/levi/public_html/mysql2.php on line 10 (If I remove the mysql_close($conn1); it works) (If I remove the $conn1 = null; it also works) -- Edit this bug report at http://bugs.php.net/?id=30525&edit=1
#32880 [Opn->Bgs]: Unable to properly convert from ISO-8859-1 to UTF-8
ID: 32880 Updated by: [EMAIL PROTECTED] Reported By: Diomedes_01 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Solaris 9 PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. What you're getting is really UTF-8 encoded string.. Previous Comments: [2005-04-28 23:46:20] Diomedes_01 at yahoo dot com Description: I am unable to properly encode certain strings from ISO-8859-1 to UTF-8. I have tried using utf8_encode, mb_convert_encoding and iconv with no success. The code I am attempting this on is as follows: Reproduce code: --- "; // Properly displays ISO-8859-1 // First try converting with iconv $iconv_test = iconv("ISO-8859-1", "UTF-8", $main_test_string); echo "Iconv test: $iconv_test"; // Displays nothing. No data whatsoever // Now try converting with mb_convert_encoding $mb_test = mb_convert_encoding($main_test_string, "UTF-8", "ISO-8859-1"); $string_test2 = mb_detect_encoding($mb_test, 'UTF-8, ISO-8859-1'); echo "Encoding used: $string_test2"; // Indicates string is now UTF-8 encoded (which is wrong) echo "MB Test convert value: $mb_test"; // Displays: référendum sur la Constitution européenne; doesn't look like UTF-8 to me // Finally try utf8_encode $utf8_encode_test = utf8_encode($main_test_string); $string_test3 = mb_detect_encoding($textfieldabstract, 'UTF-8, ISO-8859-1'); echo "Encoding used: $string_test3"; // Indicates string is now UTF-8 encoded (which is wrong) echo "Abstract post conversion: $utf8_encode_test"; // Same as before, displays: référendum sur la Constitution européenne ?> Expected result: I should be seeing UTF-8 (Unicode) translated text of the style: 'Ελληνι' Note that the above does work for non-latin based character sets like chinese, japanese, russian, greek, etc. Actual result: -- What I am seeing is the following string: référendum sur la Constitution européenne Definately not UTF-8. Could be Klingon. :-) I will admit I am not a Unicode master but this is certainly quite puzzling. According to the documentation, iconv is supposed to work in this case but it is not displaying any data. I am running PHP 5.0.4 with iconv enabled. (I see it in my phpinfo output) Please advise. -- Edit this bug report at http://bugs.php.net/?id=32880&edit=1
#32878 [Opn->Bgs]: iframe and session problems
ID: 32878 Updated by: [EMAIL PROTECTED] Reported By: iztok dot polanic at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows XP PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. RTFM: http://www.php.net/manual/en/function.session-write-close.php Previous Comments: [2005-04-28 22:21:17] iztok dot polanic at gmail dot com Description: PHP seems to have some problems with frames, in my case iframes. I noticed this error when I tried to load one template in two separate iframes. If they are loaded simultanously there comes to a problem with session variables getting lost. And also getting Permission denied(13) in session_start(). As it seems PHP doesn't check if the session file is already in use. To reproduce the actual result, you have to click on a link 'odpri' atleast 5-15 times Reproduce code: --- main.php odpri left.php right.php Expected result: iztok Actual result: -- Warning: session_start() [function.session-start]: open(c:\php\sessiondata\sess_793ef570090b599c6d973dfc64696a46, O_RDWR) failed: Permission denied (13) in C:\Documents and Settings\Iztok\My Documents\My Website\left.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=32878&edit=1
#32881 [Bgs->WFx]: php_check_syntax / require_once
ID: 32881 Updated by: [EMAIL PROTECTED] Reported By: zapco dot bo197_php at gadz dot org -Status: Bogus +Status: Wont fix -Bug Type: Unknown/Other Function +Bug Type: *General Issues Operating System: windows XP PHP Version: 5.0.4 New Comment: php_check_syntax() will be removed in next PHP versions due to the fact that it can't be made reliable/stable, ever. So plain and simple: Do not use it. It's dangerous. Use something like 'system("php -l foo.php");' to check the syntax.. Previous Comments: [2005-04-29 01:38:51] [EMAIL PROTECTED] php_check_syntax() function is removed as of PHP 5.0.5 [2005-04-29 01:12:51] zapco dot bo197_php at gadz dot org Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit this bug report at http://bugs.php.net/?id=32881&edit=1
#27406 [Asn->WFx]: php_check_syntax executes code
ID: 27406 Updated by: [EMAIL PROTECTED] Reported By: thomas at stauntons dot org -Status: Assigned +Status: Wont fix -Bug Type: Unknown/Other Function +Bug Type: *General Issues -Operating System: All +Operating System: * -PHP Version: php5.0-200412100930 +PHP Version: 5.* Assigned To: iliaa New Comment: This was fixed by removing the function altogether. It was nice idea but not one that could ever work reliably/be stable. Use something like 'system("php -l foo.php");' to check the syntax.. Previous Comments: [2005-03-26 02:43:14] patrick at 5etdemi dot com If the file that is syntax checked has includes, the includes won't be executed. That means as soon as you use php_check_syntax on such a file, you won't be able to include it and you won't be able to use it either because it's included files are MIA. That makes the function pretty useless for any practical purposes. [2005-03-07 22:59:52] linus at mccabe dot nu Another important use for this function would be when using eval()'s to test the code before eval'ing it. In this case a string would be the only option and declaring functions would definately not work... Since this function isn't experimental any more, I assume it cant be altered to do this, but a new one would need to be implemented? [2005-03-03 08:30:18] phpbugs at majiclab dot com I would have to agree with most of the other posters, that the php_check_syntax() function as it stands right now does MORE than its name implies. I feel that a true php_check_syntax() function that STRICTLY checks the syntax of a file or string and returns TRUE/FALSE and has reference to an error message is the best. In fact, I would also like to see the possibility of having an additional reference variable for the line number of an error. I am developing a fairly advanced framework that does compile certain aspects of a web site dynamically. At first glance, I tried to implement this function to check the syntax of the file both before saving it and even before including it in the future. However, I ran into some confusing messages about my classes being redefined and I couldn't understand until I read the docs closer. The simple fact is that the REAL functionality of this function is the syntax checking, NOT the including. Any PHP programmer with more than 5 minutes of experience can probably include an external file. So adding that particular aspect of the functionality to php_check_syntax() seems useless. The code I have in my system goes a little like this: Now, I started getting errors all of a sudden saying that a class in the file being included is being redeclared. I thought that odd since I set $bOnce = TRUE, so it shouldn't ever be included more than once. I think ideally I should be able to do this: Basically, it should: 1. Not include the file at all, just strictly do a lint check. 2. It would be nice to be able to get the line number of the file (for debugging purposes). At the lowest level, this function should be able to run like described by many others: It should be up to the PHP programmer to include the file... [2005-02-23 17:32:01] de_bruut at hotmail dot com Couple of points: 1. there are already half a dozen functions that include files or execute strings 2. there's no other function that allows you to check the validity of a piece of php code 3. right now, php_check_syntax does more than its name implies (it includes the file) 4. there are several situations where a 'clean' lint check of php code is useful (snippet submissions, UNIT TESTS(!), ...) 5. in general, functions should do only one thing, not two only slightly related things, and one of them badly I would love to see php_check_syntax implemented as its name implies: a lint check for a STRING. Not a file (see Wylie's comment), because there are enough functions to read a file or stream into a string. If someone wants to include the file afterwards, they only need to add a single line of code, or they can write their own two-line function. This even leaves them the choice between include() and include_once(), something which php_check_syntax does not do at this point. Did I mention the potential value of php_check_syntax for >> UNIT TESTS << yet? php_check_syntax would allow us to check the syntax of a file (string) as the first of a group of tests for that file/class, and thus avoiding a potential fatal error, which could interrupt an entire set of tests on multiple files. Thus, a syntax check could make quite a number of very serious PHP developers very happy. Not much point if php_check_syntax immediately includes the f
#32881 [Opn->Bgs]: php_check_syntax / require_once
ID: 32881 Updated by: [EMAIL PROTECTED] Reported By: zapco dot bo197_php at gadz dot org -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows XP PHP Version: 5.0.4 New Comment: php_check_syntax() function is removed as of PHP 5.0.5 Previous Comments: [2005-04-29 01:12:51] zapco dot bo197_php at gadz dot org Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit this bug report at http://bugs.php.net/?id=32881&edit=1
#32881 [NEW]: php_check_syntax / require_once
From: zapco dot bo197_php at gadz dot org Operating system: windows XP PHP version: 5.0.4 PHP Bug Type: Unknown/Other Function Bug description: php_check_syntax / require_once Description: I have some problems with the function php_check_syntax, require_once and ReflectionClass. when I use the script at this page : http://zapco.free.fr/bug.txt , I don't know if the included file (fichier_a.php or fichier_b.php in my exemple) herite or not from an other class, so index_x.php haven't the same result if the class in file used herite or not from an other class. -- Edit bug report at http://bugs.php.net/?id=32881&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32881&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32881&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32881&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32881&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32881&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32881&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32881&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32881&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32881&r=support Expected behavior: http://bugs.php.net/fix.php?id=32881&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32881&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32881&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32881&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32881&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32881&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32881&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32881&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32881&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32881&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32881&r=mysqlcfg
#32680 [Opn->Asn]: PHP_MSHUTDOWN PHP_MINIT
ID: 32680 Updated by: [EMAIL PROTECTED] Reported By: dejan at akton dot si -Status: Open +Status: Assigned Bug Type: SNMP related Operating System: * PHP Version: 4CVS, 5CVS (2005-04-15) Assigned To: sniper New Comment: I need to test this with Apache1 sometime, but atm I have no time. (I use Apache2 myself) If you can, do try with Apache2 to see if the problem disappears. Previous Comments: [2005-04-26 14:17:18] dejan at akton dot si Same thing happened. Any clues as to what is causing this problem? Is this a specific problem only on my computer? [2005-04-25 23:57:15] [EMAIL PROTECTED] Try this configure line: # ./configure --disable-all --with-apxs=/usr/local/apache/bin/apxs --with-snmp=/usr/local Using this snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz [2005-04-25 08:27:52] dejan at akton dot si My configure line: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-zlib' '--enable-bcmath' '--enable-calendar' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-exif' '--enable-ftp' '--with-gd' '--with-t1lib' '--with-gettext' '--with-imap=/usr/include/imap' '--with-mysql=/usr/local' '--with-ncurses' '--enable-pcntl' '--with-readline' '--with-snmp=/usr/local' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-msdblib' '--enable-dbmfix' '--with-tdsver=7.0' '--with-freetds=/usr/local' '--with-mssql' '--with-openssl' '--with-ttf' '--with-freetype-dir=/usr/local' '--disable-ipv6' '--disable-debug' '--enable-dio' Apache Version: Apache/1.3.29 I tried with two net-snmp versions, including the new one 5.2.1 PHP_MINIT should be called with every request to a PHP script via Apache? And PHP_MSHUTDOWN when script ends? [2005-04-23 23:31:34] [EMAIL PROTECTED] I can not reproduce this. What apache version are you using? What configure line did you use with PHP? [2005-04-15 14:04:28] [EMAIL PROTECTED] It was me who added the MSHUTDOWN() to get rid of the memleaks..fixing. 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/32680 -- Edit this bug report at http://bugs.php.net/?id=32680&edit=1
#32869 [Opn->Bgs]: Session and reference related
ID: 32869 Updated by: [EMAIL PROTECTED] Reported By: thomas dot ene at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows PHP Version: 4.3.9 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This has nothing to do with sessions. (same happens if you replace $_SESSION['aaa'] with e.g. $bar) Please read this manual page and try to understand how references work: http://www.php.net/manual/en/language.references.php Previous Comments: [2005-04-28 17:31:31] thomas dot ene at gmail dot com Description: Let's say I have a class c1. Doing this: $obj = &$_SESSION['obj']; $obj = &new c1(); would set $_SESSION['obj'] to NULL. Reproduce code: --- v = $a; } function say() { print "{$this->v}"; } } session_start(); session_destroy(); $obj = &$_SESSION['aaa']; $obj = &new c1(6); var_dump($_SESSION['aaa']); ?> Expected result: I would expect to have an object in the $_SESSION['aaa'] Actual result: -- The actual result is NULL. Sorry if this is post in not pertinent but I haven't found any support related to this. -- Edit this bug report at http://bugs.php.net/?id=32869&edit=1
#32880 [NEW]: Unable to properly convert from ISO-8859-1 to UTF-8
From: Diomedes_01 at yahoo dot com Operating system: Solaris 9 PHP version: 5.0.4 PHP Bug Type: Strings related Bug description: Unable to properly convert from ISO-8859-1 to UTF-8 Description: I am unable to properly encode certain strings from ISO-8859-1 to UTF-8. I have tried using utf8_encode, mb_convert_encoding and iconv with no success. The code I am attempting this on is as follows: Reproduce code: --- "; // Properly displays ISO-8859-1 // First try converting with iconv $iconv_test = iconv("ISO-8859-1", "UTF-8", $main_test_string); echo "Iconv test: $iconv_test"; // Displays nothing. No data whatsoever // Now try converting with mb_convert_encoding $mb_test = mb_convert_encoding($main_test_string, "UTF-8", "ISO-8859-1"); $string_test2 = mb_detect_encoding($mb_test, 'UTF-8, ISO-8859-1'); echo "Encoding used: $string_test2"; // Indicates string is now UTF-8 encoded (which is wrong) echo "MB Test convert value: $mb_test"; // Displays: référendum sur la Constitution européenne; doesn't look like UTF-8 to me // Finally try utf8_encode $utf8_encode_test = utf8_encode($main_test_string); $string_test3 = mb_detect_encoding($textfieldabstract, 'UTF-8, ISO-8859-1'); echo "Encoding used: $string_test3"; // Indicates string is now UTF-8 encoded (which is wrong) echo "Abstract post conversion: $utf8_encode_test"; // Same as before, displays: référendum sur la Constitution européenne ?> Expected result: I should be seeing UTF-8 (Unicode) translated text of the style: 'Ελληνι' Note that the above does work for non-latin based character sets like chinese, japanese, russian, greek, etc. Actual result: -- What I am seeing is the following string: référendum sur la Constitution européenne Definately not UTF-8. Could be Klingon. :-) I will admit I am not a Unicode master but this is certainly quite puzzling. According to the documentation, iconv is supposed to work in this case but it is not displaying any data. I am running PHP 5.0.4 with iconv enabled. (I see it in my phpinfo output) Please advise. -- Edit bug report at http://bugs.php.net/?id=32880&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32880&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32880&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32880&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32880&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32880&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32880&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32880&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32880&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32880&r=support Expected behavior: http://bugs.php.net/fix.php?id=32880&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32880&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32880&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32880&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32880&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32880&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32880&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32880&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32880&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32880&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32880&r=mysqlcfg
#32878 [NEW]: iframe and session problems
From: iztok dot polanic at gmail dot com Operating system: Windows XP PHP version: 5.0.4 PHP Bug Type: Session related Bug description: iframe and session problems Description: PHP seems to have some problems with frames, in my case iframes. I noticed this error when I tried to load one template in two separate iframes. If they are loaded simultanously there comes to a problem with session variables getting lost. And also getting Permission denied(13) in session_start(). As it seems PHP doesn't check if the session file is already in use. To reproduce the actual result, you have to click on a link 'odpri' atleast 5-15 times Reproduce code: --- main.php odpri left.php right.php Expected result: iztok Actual result: -- Warning: session_start() [function.session-start]: open(c:\php\sessiondata\sess_793ef570090b599c6d973dfc64696a46, O_RDWR) failed: Permission denied (13) in C:\Documents and Settings\Iztok\My Documents\My Website\left.php on line 1 -- Edit bug report at http://bugs.php.net/?id=32878&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32878&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32878&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32878&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32878&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32878&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32878&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32878&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32878&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32878&r=support Expected behavior: http://bugs.php.net/fix.php?id=32878&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32878&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32878&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32878&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32878&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32878&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32878&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32878&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32878&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32878&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32878&r=mysqlcfg
#32850 [Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) New Comment: PHP crashes in the second I invoke ./php Like the backtrace shows it dies when loading sqlite extension because it ends up calling zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) <--- with a 0x0 NULL pointer Previous Comments: [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? [2005-04-27 12:04:51] [EMAIL PROTECTED] Description: #0 zend_hash_merge_ex (target=0x82f2d38, source=0x98, pCopyConstructor=0x81d6e10 , size=4, pMergeSource=0x81c8ec0 , pParam=0x0) at /home/.../php5-200504251230/Zend/zend_hash.c:818 p = (Bucket *) 0x82f2ca0 t = (void *) 0x82f4908 #1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) at /home/.../php5-200504251230/Zend/zend_compile.c:2099 No locals. #2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0, num_interfaces=2) at /home/.../php5-200504251230/Zend/zend_API.c:1646 interface_entry = (zend_class_entry *) 0x98 ce_num = 2 impl_num = 2 interface_list = 0xb390 "è#@ ¦/@\214" #3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at /home/.../php5-200504251230/ext/sqlite/sqlite.c:1024 No locals. #4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at /home/.../php5-200504251230/Zend/zend_API.c:1227 lcname = 0x0 module_ptr = (zend_module_entry *) 0x82f0028 #5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at /home/.../php5-200504251230/main/main.c:1269 end = (zend_module_entry **) 0x82a453c #6 0x08246d2b in php_startup_internal_extensions () at main/internal_functions_cli.c:72 No locals. #7 0x081a13ea in php_module_startup (sf=0x828396c, additional_modules=0x0, num_additional_modules=152) at /home/.../php5-200504251230/main/main.c:1454 zuf = {error_function = 0x819fbb0 , printf_function = 0x819f510 , write_function = 0x81a0d70 , fopen_function = 0x81a0220 , message_handler = 0x81a0340 , block_interruptions = 0, unblock_interruptions = 0, get_configuration_directive = 0x81a02f0 , ticks_function = 0x81abd60 , on_timeout = 0x81a0480 , stream_open_function = 0x81a0270 , vspprintf_function = 0x81a42c0 , getenv_function = 0x81a7620 } zuv = {import_use_extension = 0x82576e6 ".php", import_use_extension_length = 136766146, html_errors = 1 '\001'} #8 0x08245c9e in main (argc=1, argv=0xbbd4) at /home/.../php5-200504251230/sapi/cli/php_cli.c:632 exit_status = 0 c = 152 file_handle = {type = 0 '\0', filename = 0x82a46f4 "[EMAIL PROTECTED]", opened_path = 0xbb28 "Hûÿ¿Ûs$\bÜûÿ¿`\234/@", handle = {fd = 134697609, fp = 0x8075289, stream = {handle = 0x8075289, reader = 0x402f9c50 , closer = 0xbb34, interactive = -1073743032}}, free_filename = 219 'Û'} -- Edit this bug report at http://bugs.php.net/?id=32850&edit=1
#32850 [Ctl->Fbk]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Feedback Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) Previous Comments: [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? [2005-04-27 12:04:51] [EMAIL PROTECTED] Description: #0 zend_hash_merge_ex (target=0x82f2d38, source=0x98, pCopyConstructor=0x81d6e10 , size=4, pMergeSource=0x81c8ec0 , pParam=0x0) at /home/.../php5-200504251230/Zend/zend_hash.c:818 p = (Bucket *) 0x82f2ca0 t = (void *) 0x82f4908 #1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) at /home/.../php5-200504251230/Zend/zend_compile.c:2099 No locals. #2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0, num_interfaces=2) at /home/.../php5-200504251230/Zend/zend_API.c:1646 interface_entry = (zend_class_entry *) 0x98 ce_num = 2 impl_num = 2 interface_list = 0xb390 "è#@ ¦/@\214" #3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at /home/.../php5-200504251230/ext/sqlite/sqlite.c:1024 No locals. #4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at /home/.../php5-200504251230/Zend/zend_API.c:1227 lcname = 0x0 module_ptr = (zend_module_entry *) 0x82f0028 #5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at /home/.../php5-200504251230/main/main.c:1269 end = (zend_module_entry **) 0x82a453c #6 0x08246d2b in php_startup_internal_extensions () at main/internal_functions_cli.c:72 No locals. #7 0x081a13ea in php_module_startup (sf=0x828396c, additional_modules=0x0, num_additional_modules=152) at /home/.../php5-200504251230/main/main.c:1454 zuf = {error_function = 0x819fbb0 , printf_function = 0x819f510 , write_function = 0x81a0d70 , fopen_function = 0x81a0220 , message_handler = 0x81a0340 , block_interruptions = 0, unblock_interruptions = 0, get_configuration_directive = 0x81a02f0 , ticks_function = 0x81abd60 , on_timeout = 0x81a0480 , stream_open_function = 0x81a0270 , vspprintf_function = 0x81a42c0 , getenv_function = 0x81a7620 } zuv = {import_use_extension = 0x82576e6 ".php", import_use_extension_length = 136766146, html_errors = 1 '\001'} #8 0x08245c9e in main (argc=1, argv=0xbbd4) at /home/.../php5-200504251230/sapi/cli/php_cli.c:632 exit_status = 0 c = 152 file_handle = {type = 0 '\0', filename = 0x82a46f4 "[EMAIL PROTECTED]", opened_path = 0xbb28 "Hûÿ¿Ûs$\bÜûÿ¿`\234/@", handle = {fd = 134697609, fp = 0x8075289, stream = {handle = 0x8075289, reader = 0x402f9c50 , closer = 0xbb34, interactive = -1073743032}}, free_filename = 219 'Û'} -- Edit this bug report at http://bugs.php.net/?id=32850&edit=1
#32850 [Ctl]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) New Comment: Any info on how to reproduce it? Previous Comments: [2005-04-27 12:04:51] [EMAIL PROTECTED] Description: #0 zend_hash_merge_ex (target=0x82f2d38, source=0x98, pCopyConstructor=0x81d6e10 , size=4, pMergeSource=0x81c8ec0 , pParam=0x0) at /home/.../php5-200504251230/Zend/zend_hash.c:818 p = (Bucket *) 0x82f2ca0 t = (void *) 0x82f4908 #1 0x081c8f79 in zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) at /home/.../php5-200504251230/Zend/zend_compile.c:2099 No locals. #2 0x081dbfa9 in zend_class_implements (class_entry=0x82f2ca0, num_interfaces=2) at /home/.../php5-200504251230/Zend/zend_API.c:1646 interface_entry = (zend_class_entry *) 0x98 ce_num = 2 impl_num = 2 interface_list = 0xb390 "è#@ ¦/@\214" #3 0x080f6102 in zm_startup_sqlite (type=1, module_number=4) at /home/.../php5-200504251230/ext/sqlite/sqlite.c:1024 No locals. #4 0x081daf38 in zend_register_module_ex (module=0x82f0028) at /home/.../php5-200504251230/Zend/zend_API.c:1227 lcname = 0x0 module_ptr = (zend_module_entry *) 0x82f0028 #5 0x081a0dc0 in php_startup_extensions (ptr=0x82a450c, count=152) at /home/.../php5-200504251230/main/main.c:1269 end = (zend_module_entry **) 0x82a453c #6 0x08246d2b in php_startup_internal_extensions () at main/internal_functions_cli.c:72 No locals. #7 0x081a13ea in php_module_startup (sf=0x828396c, additional_modules=0x0, num_additional_modules=152) at /home/.../php5-200504251230/main/main.c:1454 zuf = {error_function = 0x819fbb0 , printf_function = 0x819f510 , write_function = 0x81a0d70 , fopen_function = 0x81a0220 , message_handler = 0x81a0340 , block_interruptions = 0, unblock_interruptions = 0, get_configuration_directive = 0x81a02f0 , ticks_function = 0x81abd60 , on_timeout = 0x81a0480 , stream_open_function = 0x81a0270 , vspprintf_function = 0x81a42c0 , getenv_function = 0x81a7620 } zuv = {import_use_extension = 0x82576e6 ".php", import_use_extension_length = 136766146, html_errors = 1 '\001'} #8 0x08245c9e in main (argc=1, argv=0xbbd4) at /home/.../php5-200504251230/sapi/cli/php_cli.c:632 exit_status = 0 c = 152 file_handle = {type = 0 '\0', filename = 0x82a46f4 "[EMAIL PROTECTED]", opened_path = 0xbb28 "Hûÿ¿Ûs$\bÜûÿ¿`\234/@", handle = {fd = 134697609, fp = 0x8075289, stream = {handle = 0x8075289, reader = 0x402f9c50 , closer = 0xbb34, interactive = -1073743032}}, free_filename = 219 'Û'} -- Edit this bug report at http://bugs.php.net/?id=32850&edit=1
#32874 [Opn->Bgs]: Circular call leeds to segmentation fault
ID: 32874 Updated by: [EMAIL PROTECTED] Reported By: mbm at interflow dot dk -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Multiple OS PHP Version: 5.0.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2005-04-28 20:28:23] mbm at interflow dot dk Description: Recursively calling two functions in a class leads to a segmentation fault. Reproduce code: --- class SegFault { public function call(){ $this->back(); } public function back(){ $this->call(); } } $seg = new SegFault(); $seg->Call(); Expected result: I'd expect some kind of error when php runs out of buffer for the callstack - this function clearly is an example of bad code in the script - however php shouldnt die by segmentation fault. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=32874&edit=1
#32875 [Opn->Bgs]: Repetition quantifiers
ID: 32875 Updated by: [EMAIL PROTECTED] Reported By: chiaroscuro at achromatic dot fsnet dot co dot uk -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Apache 1.3.31 PHP Version: 4.3.10 New Comment: Anchor your regex using ^ and $ Previous Comments: [2005-04-28 20:52:02] chiaroscuro at achromatic dot fsnet dot co dot uk Description: I'm using quantifiers in preg_match_all functions,amongst other things, to restrict the length of strings strings submitted from HTML forms. The lower limit catches discrepant strings, but the upper limit has no effect. I've tried using very basic code, but unsuccessfully. Reproduce code: --- $failure = 0; $userpattern = "/t{3,6}/"; $username = 'ttt'; $usercheck = preg_match_all($userpattern,$username,$results); if ( !$usercheck ) { $failure++; } Expected result: $usercheck = 'tt'; This would be a disallowed string $usercheck = 'ttt'; This would also be a disallowed string Actual result: -- $usercheck = 'tt'; results in $failure == 1 & the string 'fails' as it should. $usercheck = 'ttt'; results in $failure = 0 & the string is allowed. This happens however many repetitions the string comprises and with any upper limit set. -- Edit this bug report at http://bugs.php.net/?id=32875&edit=1
#32875 [NEW]: Repetition quantifiers
From: chiaroscuro at achromatic dot fsnet dot co dot uk Operating system: Apache 1.3.31 PHP version: 4.3.10 PHP Bug Type: PCRE related Bug description: Repetition quantifiers Description: I'm using quantifiers in preg_match_all functions,amongst other things, to restrict the length of strings strings submitted from HTML forms. The lower limit catches discrepant strings, but the upper limit has no effect. I've tried using very basic code, but unsuccessfully. Reproduce code: --- $failure = 0; $userpattern = "/t{3,6}/"; $username = 'ttt'; $usercheck = preg_match_all($userpattern,$username,$results); if ( !$usercheck ) { $failure++; } Expected result: $usercheck = 'tt'; This would be a disallowed string $usercheck = 'ttt'; This would also be a disallowed string Actual result: -- $usercheck = 'tt'; results in $failure == 1 & the string 'fails' as it should. $usercheck = 'ttt'; results in $failure = 0 & the string is allowed. This happens however many repetitions the string comprises and with any upper limit set. -- Edit bug report at http://bugs.php.net/?id=32875&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32875&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32875&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32875&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32875&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32875&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32875&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32875&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32875&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32875&r=support Expected behavior: http://bugs.php.net/fix.php?id=32875&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32875&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32875&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32875&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32875&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32875&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32875&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32875&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32875&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32875&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32875&r=mysqlcfg
#32874 [NEW]: Circular call leeds to segmentation fault
From: mbm at interflow dot dk Operating system: Multiple OS PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: Circular call leeds to segmentation fault Description: Recursively calling two functions in a class leads to a segmentation fault. Reproduce code: --- class SegFault { public function call(){ $this->back(); } public function back(){ $this->call(); } } $seg = new SegFault(); $seg->Call(); Expected result: I'd expect some kind of error when php runs out of buffer for the callstack - this function clearly is an example of bad code in the script - however php shouldnt die by segmentation fault. Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=32874&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32874&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32874&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32874&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32874&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32874&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32874&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32874&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32874&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32874&r=support Expected behavior: http://bugs.php.net/fix.php?id=32874&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32874&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32874&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32874&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32874&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32874&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32874&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32874&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32874&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32874&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32874&r=mysqlcfg
#32873 [Opn->Bgs]: file_get_contents appends \n
ID: 32873 Updated by: [EMAIL PROTECTED] Reported By: mbm at interflow dot dk -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: FreeBSD 5.2 PHP Version: 5.0.3 New Comment: The echo shell command does this by default. Use "echo -n" to prevent it. Previous Comments: [2005-04-28 20:17:06] mbm at interflow dot dk Description: When loading a file with file_get_contents theres an \n appended to the content. Reproduce code: --- echo "foo" > file.txt php -r 'var_dump(file_get_contents("file.txt"));' Expected result: string(3) "foo" Actual result: -- string(4) "foo " -- Edit this bug report at http://bugs.php.net/?id=32873&edit=1
#32873 [NEW]: file_get_contents appends \n
From: mbm at interflow dot dk Operating system: FreeBSD 5.2 PHP version: 5.0.3 PHP Bug Type: Filesystem function related Bug description: file_get_contents appends \n Description: When loading a file with file_get_contents theres an \n appended to the content. Reproduce code: --- echo "foo" > file.txt php -r 'var_dump(file_get_contents("file.txt"));' Expected result: string(3) "foo" Actual result: -- string(4) "foo " -- Edit bug report at http://bugs.php.net/?id=32873&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32873&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32873&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32873&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32873&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32873&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32873&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32873&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32873&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32873&r=support Expected behavior: http://bugs.php.net/fix.php?id=32873&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32873&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32873&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32873&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32873&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32873&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32873&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32873&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32873&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32873&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32873&r=mysqlcfg
#29015 [Ver->Csd]: Incorrect behavior of member vars(non string ones)-numeric mem vars und others
ID: 29015 Updated by: [EMAIL PROTECTED] Reported By: tomas_matousek at hotmail dot com -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2005-03-06 New Comment: Fixed in CVS HEAD and PHP_5_0. Empty property and string properties started with '\0' are disallowed. Previous Comments: [2004-08-14 00:43:06] php at hristov dot com AFAUK, internally the private member variables are stored in such a way that the first byte is \0, which maybe you emulate with your test case. ":private" means that the member var is private one. shorter example for "creating" of a private variable : php -r '$a=new stdclass();$a->$b=3;var_dump($a);' and of "integer" member variable php -r '$a=new stdclass();$b=3;$a->$b=3;var_dump($a);' andrey [2004-07-05 15:02:12] tomas_matousek at hotmail dot com Description: If I try to use variable with non-string name (e.g. $x = 10; $$x = ...) the name is converted to a string using standard conversion rules. That's ok. But this doesn't work on object's field which is IMHO a bug and it implies some a buggy behavior. See the code bellow. It seems that by: $x = null; $a->$x = "whatever"; one can somehow create a private variable (or something like that, don't know what ":private" means)! Moreover, there is possibly a bug in get_object_vars when a field name is a numeric string (e.g. "10") (compare the first item of results of get_object_vars and var_dump). Reproduce code: --- function field_names_test() { $a = new stdClass(); $x = 10; $a->$x = "int(10)"; $x = "10"; $a->$x = "string('10')"; $x = ""; $a->$x = "string('')"; $x = null; $a->$x = "null"; $x = 1.8; $a->$x = "double(1.8)"; $x = false; $a->$x = "bool(false)"; $x = array(1,2,3); $a->$x = "array(1,2,3)"; var_dump(get_object_vars($a)); var_dump($a); } field_names_test(); Expected result: array(4) { ["10"]=> string(12) "string('10')" [""]=> string(11) "bool(false)" ["1.8"]=> string(11) "double(1.8)" ["Array"]=> string(12) "array(1,2,3)" } object(stdClass)#1 (4) { ["10"]=> string(12) "string('10')" [""]=> string(11) "bool(false)" ["1.8"]=> string(11) "double(1.8)" ["Array"]=> string(12) "array(1,2,3)" } Actual result: -- array(3) { [10]=> string(12) "string('10')" ["1.8"]=> string(11) "double(1.8)" ["Array"]=> string(12) "array(1,2,3)" } object(stdClass)#1 (4) { ["10"]=> string(12) "string('10')" [":private"]=> string(11) "bool(false)" ["1.8"]=> string(11) "double(1.8)" ["Array"]=> string(12) "array(1,2,3)" } -- Edit this bug report at http://bugs.php.net/?id=29015&edit=1
#32859 [Fbk->Opn]: Error when attempting to write Clob to oracle
ID: 32859 User updated by: Diomedes_01 at yahoo dot com Reported By: Diomedes_01 at yahoo dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 New Comment: Unfortunately, my website is behind a firewall and contains company sensitive information; so I cannot grant access. The reproducible code is already included; please note that I attempted to continue using my previous PHP4 code (that worked beforehand) and it failed. That code was: WriteTemporary($comments); OCIExecute ($sth, OCI_DEFAULT) or display_main_error(); $clob->close(); $clob->free(); OCIFreeStatement($sth); ?> When I attempted to execute the above code, I received a fatal error from PHP indicating that the writeTemporary method was not found. According to what I read in the documentation, it appears to not be part of the new OCI class. So when I followed the documentation and re-implemented the code following the instructions provided; which by the way, look like so: (straight from your online help) = 4.0.6). * Example PL/SQL stored procedure signature is: * * PROCEDURE save_data * Argument Name TypeIn/Out Default? * -- --- -- * KEYNUMBER(38) IN * DATA CLOBIN * */ $conn = oci_connect($user, $password); $stmt = oci_parse($conn, "begin save_data(:key, :data); end;"); $clob = oci_new_descriptor($conn, OCI_D_LOB); oci_bind_by_name($stmt, ':key', $key); oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB); $clob->write($data); oci_execute($stmt, OCI_DEFAULT); oci_commit($conn); $clob->free(); oci_free_statement($stmt); ?> Here is the documentation URL: http://us2.php.net/manual/en/function.oci-new-descriptor.php That is when I receive a problem with regards to the 'write' method. So either this is a bug or a documentation problem; I know the stored procedure I am using works and that the variables being passed are valid. It works in SQL*Plus and it works if I revert back to PHP4. Please advise. Previous Comments: [2005-04-28 15:04:53] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Also, you don't have to modify your script to make it run with PHP5. Old-style named functions are working in the same way as in PHP4. [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = ("begin append_comments(:incident_id,:comments_id);end;"); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, ":incident_id", $incident ); oci_bind_by_name ($sth, ":comments_id", &$clob, -1, OCI_B_CLOB ); $clob->write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob->free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at "SYS.DBMS_LOB", line 366 ORA-06512: at "ETRACK.APPEND_COMMENTS", line 14 ORA-06512: at line 1 in /www/htdocs/EtrackTest/oracle_update.php on line 219 The code I use is virtually identical to what exists in the PHP documentation. -- Edit this bug report at http://bugs.php.net/?id=32859&edit=1
#32868 [Csd->Bgs]: Although localeconv() reports , for decimal_point calculations fail
ID: 32868 Updated by: [EMAIL PROTECTED] Reported By: andy at laut dot de -Status: Closed +Status: Bogus Bug Type: *General Issues Operating System: SuSe Linux 9.2 PHP Version: 4.3.10 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 This is actually the intended behaviours, PHP only uses the "." for as the decimal separators regardless of the locale. Previous Comments: [2005-04-28 17:35:29] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-04-28 16:59:46] andy at laut dot de Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP <4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print("1,00+1,99=" . "1,00" + "1,99" . "\n"); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2 5 -- Edit this bug report at http://bugs.php.net/?id=32868&edit=1
#32870 [NEW]: Setting "output_handler" does not work with custom functions
From: ng4rrjanbiah at rediffmail dot com Operating system: Windows XP PHP version: 5.0.4 PHP Bug Type: Output Control Bug description: Setting "output_handler" does not work with custom functions Description: Setting output_handler (either through php.ini our .htaccess) does not work with custom functions. It works for "ob_gzhandler" but *not* on any custom functions--say "foo". There was a detail discussion on c.l.php about this http://groups.google.com/[EMAIL PROTECTED] Though we could set custom callback functions through ob_start(), we couldn't set output_handler (for custom functions) via php.ini. The manual also hints that it could be set PHP_INI_PERDIR basis http://in2.php.net/ref.outcontrol#AEN111555 Peace to you all PHP saints... -R. Rajesh Jeba Anbiah Reproduce code: --- in php.ini set: output_handler "foo_callback" in test.php: Expected result: "foo_callback" to be listed Actual result: -- nothing. (Callback not registered.) -- Edit bug report at http://bugs.php.net/?id=32870&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32870&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32870&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32870&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32870&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32870&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32870&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32870&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32870&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32870&r=support Expected behavior: http://bugs.php.net/fix.php?id=32870&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32870&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32870&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32870&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32870&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32870&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32870&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32870&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32870&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32870&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32870&r=mysqlcfg
#32869 [NEW]: Session and reference related
From: thomas dot ene at gmail dot com Operating system: Windows PHP version: 4.3.9 PHP Bug Type: Session related Bug description: Session and reference related Description: Let's say I have a class c1. Doing this: $obj = &$_SESSION['obj']; $obj = &new c1(); would set $_SESSION['obj'] to NULL. Reproduce code: --- v = $a; } function say() { print "{$this->v}"; } } session_start(); session_destroy(); $obj = &$_SESSION['aaa']; $obj = &new c1(6); var_dump($_SESSION['aaa']); ?> Expected result: I would expect to have an object in the $_SESSION['aaa'] Actual result: -- The actual result is NULL. Sorry if this is post in not pertinent but I haven't found any support related to this. -- Edit bug report at http://bugs.php.net/?id=32869&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32869&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32869&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32869&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32869&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32869&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32869&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32869&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32869&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32869&r=support Expected behavior: http://bugs.php.net/fix.php?id=32869&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32869&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32869&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32869&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32869&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32869&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32869&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32869&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32869&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32869&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32869&r=mysqlcfg
#32868 [Opn->Csd]: Although localeconv() reports , for decimal_point calculations fail
ID: 32868 Updated by: [EMAIL PROTECTED] Reported By: andy at laut dot de -Status: Open +Status: Closed Bug Type: *General Issues Operating System: SuSe Linux 9.2 PHP Version: 4.3.10 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-04-28 16:59:46] andy at laut dot de Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP <4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print("1,00+1,99=" . "1,00" + "1,99" . "\n"); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2 5 -- Edit this bug report at http://bugs.php.net/?id=32868&edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. Previous Comments: [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#32828 [Ver->Csd]: Throwing exception in output_callback function with ob_start and ob_end_clean
ID: 32828 Updated by: [EMAIL PROTECTED] Reported By: rbro at hotmail dot com -Status: Verified +Status: Closed Bug Type: Reproducible crash Operating System: * PHP Version: 5.0,5.1 CVS (2005-04-26) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-04-26 00:52:03] rbro at hotmail dot com Description: If you throw an exception inside an output_callback function as a result of using ob_start() and ob_end_clean(), a Segmentation fault occurs. Reproduce code: --- Expected result: Exception is thrown. Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=32828&edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: quoted-string cookies are defined as cookies with a value that is a quoted-string, quoted by double-quote marks. You refer to PHP's mechanism to urlencode all cookie values resulting in TOKEN values. This mechanism is indeed suggested in netscapes standard. I've pointed the difference of these things out in my bug report. So, please don't say what I claim is wrong, because that is simply not true. Handle it as a feature request if you prefer that. It's ok. Thanks for the discussion. After all, we all agree on the state (PHP 4.3.11 implements cookie standard 0 (netscape)) and what it doesn't (RFC 2109 which is as old as PHP 2). Previous Comments: [2005-04-28 16:52:08] [EMAIL PROTECTED] You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#32868 [NEW]: Although localeconv() reports , for decimal_point calculations fail
From: andy at laut dot de Operating system: SuSe Linux 9.2 PHP version: 4.3.10 PHP Bug Type: *General Issues Bug description: Although localeconv() reports , for decimal_point calculations fail Description: There seems to be a failure in internal number formating. Although my locale is set correctly and localeconf returns the expected information, which says, that decimal_point is the komma, calculations with komma as decimal-separator fail. Versions of PHP <4.3 behave as i expect, but since 4.3 scripts which uses the komma for decimal-separator don't calculate correctly anymore... My Configure-Line: './configure' '--with-apxs=/www/apache-1.3.33/bin/apxs' '--prefix=/www/apache-1.3.33/php-4.3.10' '--with-gd' '--with-zlib' '--with-mysql' '--enable-trans-sid' '--enable-ftp' '--with-mnogosearch=/www/mnogosearch' Reproduce code: --- #As anybody can see here, the locale is set correctly setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge'); echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978)); #localeconf returns the expected information $locale_info = localeconv(); print_r($locale_info); #But what the heck, this print doesn't print("1,00+1,99=" . "1,00" + "1,99" . "\n"); /* If you uncomment this, parse error occurs $x = 2,99; $y = 3,27; print($x+$y); */ Expected result: Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2,99 6,26 Actual result: -- Freitag 22 Dezember 1978 Array ( [decimal_point] => , [thousands_sep] => . [int_curr_symbol] => EUR [currency_symbol] => ¤ [mon_decimal_point] => , [mon_thousands_sep] => . [positive_sign] => [negative_sign] => - [int_frac_digits] => 2 [frac_digits] => 2 [p_cs_precedes] => 0 [p_sep_by_space] => 1 [n_cs_precedes] => 0 [n_sep_by_space] => 1 [p_sign_posn] => 1 [n_sign_posn] => 1 [grouping] => Array ( [0] => 3 [1] => 3 ) [mon_grouping] => Array ( [0] => 3 [1] => 3 ) ) 2 5 -- Edit bug report at http://bugs.php.net/?id=32868&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32868&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32868&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32868&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32868&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32868&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32868&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32868&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32868&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32868&r=support Expected behavior: http://bugs.php.net/fix.php?id=32868&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32868&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32868&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32868&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32868&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32868&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32868&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32868&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32868&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32868&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32868&r=mysqlcfg
#32852 [Fbk->Opn]: Crash with singleton and __destruct
ID: 32852 User updated by: cox at idecnet dot com Reported By: cox at idecnet dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: Not using my php.ini doesn't crash in 5.0.4, 5.0.5dev or 5.1cvs and the output match the expected. So investigating my modified settings from the original php.ini-dist, I've found that ze1_compat generates the problem: zend.ze1_compatibility_mode = On (turning it Off does not crash, well, afterall it's php5 only syntax). The other requested data: gcc-3.4.1 bison-1.875 glibc-2.3.3 Previous Comments: [2005-04-28 13:52:55] [EMAIL PROTECTED] I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache && ./configure + your options + --enable-debug && make clean && make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852&edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. Previous Comments: [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#28074 [Asn->Csd]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream
ID: 28074 Updated by: [EMAIL PROTECTED] Reported By: bogus_idp at yahoo dot fr -Status: Assigned +Status: Closed Bug Type: CGI related Operating System: * PHP Version: 4CVS, 5CVS (2005-01-10) Assigned To: sas New Comment: Added fastcgi.logging php.ini option to make it possible for people like Sascha to disable this. Previous Comments: [2005-04-28 12:58:03] [EMAIL PROTECTED] Feel free to fix it then. [2005-04-21 11:43:51] [EMAIL PROTECTED] This is an ugly change for users who redirect PHP's stderr to a log file due to file permissions (PHP is not allowed to open the log file). Instead of writing to the log file, the Apache log now contains tons of rows like this: [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: array ( [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: 'rcs' => [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: array ( etc. This needs to be addressed -- make logging to fastcgi's stderr optional. [2005-01-10 16:01:29] chris at ex-parrot dot com This one turns out to be easy to fix, thus: --- cgi_main.c.orig Mon Jan 10 14:57:04 2005 +++ cgi_main.c Mon Jan 10 14:53:44 2005 @@ -481,7 +481,14 @@ static void sapi_cgi_log_message(char *message) { - fprintf(stderr, "%s\n", message); +#if PHP_FASTCGI +if (!FCGX_IsCGI()) { +FCGX_Request *request = (FCGX_Request *)SG(server_context); +FCGX_FPrintF( request->err, "%s\n", message ); +/* ignore return code */ +} else +#endif /* PHP_FASTCGI */ + fprintf(stderr, "%s\n", message); } static int sapi_cgi_deactivate(TSRMLS_D) However, there is another similar bug, which is that a stream opened on "php://stderr" should also direct its output to the FCGI error stream (rather than just to file descriptor #2). -- Chris Lightfoot [2004-04-20 12:03:30] bogus_idp at yahoo dot fr Description: The Fast CGI standard require that error be reported through the FastCGI connection as a Stderr data stream. But PHP Fast CGI processes still write errors to original stderr (file handle 3) which prevent from clean standard centralized FCGI logging, especially when the Fast CGI PHP process is not started by the web server (remote Fast CGI). In most cases, it makes debugging PHP scripts impossible. -- Edit this bug report at http://bugs.php.net/?id=28074&edit=1
#32859 [Opn->Fbk]: Error when attempting to write Clob to oracle
ID: 32859 Updated by: [EMAIL PROTECTED] Reported By: Diomedes_01 at yahoo dot com -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Also, you don't have to modify your script to make it run with PHP5. Old-style named functions are working in the same way as in PHP4. Previous Comments: [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = ("begin append_comments(:incident_id,:comments_id);end;"); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, ":incident_id", $incident ); oci_bind_by_name ($sth, ":comments_id", &$clob, -1, OCI_B_CLOB ); $clob->write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob->free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at "SYS.DBMS_LOB", line 366 ORA-06512: at "ETRACK.APPEND_COMMENTS", line 14 ORA-06512: at line 1 in /www/htdocs/EtrackTest/oracle_update.php on line 219 The code I use is virtually identical to what exists in the PHP documentation. -- Edit this bug report at http://bugs.php.net/?id=32859&edit=1
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866 User updated by: kevin at hatry dot com Reported By: kevin at hatry dot com Status: Bogus Bug Type: MySQL related Operating System: windows XP + linux PHP Version: 4.3.11 New Comment: i didn't think i was having a discussion just thought you hadn't seen my point and wanted to make it clear. But if you say that it is normal that "affecting "NULL" to $link1 makes $link2 to become "Unkown"" i will not bother you anymore. I understand that you are all very busy (as i am by the way, this problem has put me way behind schedule) and i am sorry that my feedback has made you lose your time. Previous Comments: [2005-04-28 14:13:35] [EMAIL PROTECTED] Please don't abuse the bug system for questions and discussions. Use PHP's mailinglists (http://www.php.net/mailing-lists.php) [2005-04-28 13:48:26] kevin at hatry dot com thank you for your direct answer however this "solution" cannot work with a heavily loaded website as it would open too much connections on the mysql server : for example a page called 50 times a second and opening 3 connections at a the same time means 150 connections /sec to the mysql server instead of 50 ! This situation is clearly one where the shared connection is useful. i will try one last example to make sure you really know how i "want it to work", please read it through and answer the last question below, thank you. the following script (without any function to make it clearer) : generate this output : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (Unknown) Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ... on line 24 mysql thread : Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on line 28 If you could please answer this one last question : why does affecting "NULL" to $link1 make $link2 to become "Unkown" ? In other words, why don't we see this output instead : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (mysql link) mysql thread : 16 If this is a feature than it should be documented as it is not obvious that changing the value of the resource variable will close the connection, even if it has been closed before. [2005-04-28 12:49:42] [EMAIL PROTECTED] Change false to true in mysql_connect() and it will work like you want it to work. Still not a bug. [2005-04-28 12:26:33] kevin at hatry dot com Description: I originally posted this info on follow up of bug id 30525 but it has been reported as bogus and i dont think the problem has been fully understood. Please *do* try to understand the problem here as there *is* one ! PHP version used : -> php 4.3.11 on win32 with the bundled 3.23.49 mysql client -> php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client both with apache 1.3.33 and with the cli binary. Preface : I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links but that there now appears to be reference counting before finally closing the TCP connection which is a better thing for me. The problem is : It seems that affecting a value or 'unset'ing a variable of type mysql resource or living the function in which the variable was created calls mysql_close on that variable (and so reduces the reference) even if a previous call was already made on that variable. So the reference count becomes wrong. So it is very hard to keep track of the real status (connected, not connected, of type mysql, of type unknown) of a mysql resource. The reproduce code is quite simple but is, i think, a typical way of programming : you have a function (or class) that query mysql by creating its own resource. Normally, with this version of PHP, the call to mysql_close should not close the shared connection so the code is ok to use. But with the bug a second call to mysl_close is made when the function returns. A last note : the same bug can be found if, instead of calling the function "do_something_in_mysql" we do $link1 = -1; after the line "mysql_close($link1);". Thank you for your time, i hope you will see the bug this time. Reproduce code: --- the bug. echo "link1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 Updated by: [EMAIL PROTECTED] Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. Previous Comments: [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. [2005-04-27 23:20:34] ast at gmx dot ch Obviously, the bug report was mangled. Here's a pretty print of the report / fix: http://nei.ch/articles/quoted_string_cookie_fix.php 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#32245 [Ver->Csd]: xml_parser_free() in a function assigned to the xml parser gives a segfault
ID: 32245 Updated by: [EMAIL PROTECTED] Reported By: MageOfChrisz at Gmail dot com -Status: Verified +Status: Closed Bug Type: XML related Operating System: Linux 2.6.10 PHP Version: 5CVS-2005-03-09 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-03-09 11:40:29] [EMAIL PROTECTED] Starting program: /usr/src/dev/php-src/sapi/cli/php /www/function_example.php [Thread debugging using libthread_db enabled] [New Thread 1080248256 (LWP 30048)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080248256 (LWP 30048)] 0x08225b82 in _xml_endElementHandler (userData=0x85813ac, name=0x856fd68 "foo") at /usr/src/dev/php-src/ext/xml/xml.c:768 768 add_assoc_string(*(parser->ctag),"type","complete",1); (gdb) bt #0 0x08225b82 in _xml_endElementHandler (userData=0x85813ac, name=0x856fd68 "foo") at /usr/src/dev/php-src/ext/xml/xml.c:768 #1 0x08228569 in _end_element_handler (user=0x8582164, name=0x857cf5f "foo") at /usr/src/dev/php-src/ext/xml/compat.c:143 #2 0x40551d57 in xmlParseTryOrFinish (ctxt=0x857fe68, terminate=0) at parser.c:9261 #3 0x4055288f in xmlParseChunk__internal_alias (ctxt=0x857fe68, chunk=0x857ce4c " \n \n \n \n \n ", size=139963800, terminate=0) at parser.c:9872 #4 0x08228ccc in php_XML_Parse (parser=0x8582164, data=0x857ce4c " \n \n \n \n \n ", data_len=113, is_final=0) at /usr/src/dev/php-src/ext/xml/compat.c:512 #5 0x08227114 in zif_xml_parse (ht=2, return_value=0x857cef4, this_ptr=0x0, return_value_used=0) at /usr/src/dev/php-src/ext/xml/xml.c:1333 #6 0x08293dec in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcbb0) at zend_vm_execute.h:175 #7 0x08296890 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffcbb0) at zend_vm_execute.h:1535 #8 0x08293b06 in execute (op_array=0x857ac9c) at zend_vm_execute.h:78 #9 0x0826f69f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/dev/php-src/Zend/zend.c:1058 #10 0x0822d0c9 in php_execute_script (primary_file=0xbfffefe0) at /usr/src/dev/php-src/main/main.c:1642 #11 0x082e2db9 in main (argc=2, argv=0xb0b4) at /usr/src/dev/php-src/sapi/cli/php_cli.c:944 (gdb) p *parser $1 = {index = 1515870810, case_folding = 1515870810, parser = 0x5a5a5a5a, target_encoding = 0x5a5a5a5a , startElementHandler = 0x5a5a5a5a, endElementHandler = 0x5a5a5a5a, characterDataHandler = 0x5a5a5a5a, processingInstructionHandler = 0x5a5a5a5a, defaultHandler = 0x5a5a5a5a, unparsedEntityDeclHandler = 0x5a5a5a5a, notationDeclHandler = 0x5a5a5a5a, externalEntityRefHandler = 0x5a5a5a5a, unknownEncodingHandler = 0x5a5a5a5a, startNamespaceDeclHandler = 0x5a5a5a5a, endNamespaceDeclHandler = 0x5a5a5a5a, startElementPtr = 0x5a5a5a5a, endElementPtr = 0x5a5a5a5a, characterDataPtr = 0x5a5a5a5a, processingInstructionPtr = 0x5a5a5a5a, defaultPtr = 0x5a5a5a5a, unparsedEntityDeclPtr = 0x5a5a5a5a, notationDeclPtr = 0x5a5a5a5a, externalEntityRefPtr = 0x5a5a5a5a, unknownEncodingPtr = 0x5a5a5a5a, startNamespaceDeclPtr = 0x5a5a5a5a, endNamespaceDeclPtr = 0x5a5a5a5a, object = 0x5a5a5a5a, data = 0x5a5a5a5a, info = 0x5a5a5a5a, level = 1515870810, toffset = 1515870810, curtag = 1515870810, ctag = 0x5a5a5a5a, ltags = 0x5a5a5a5a, lastwasopen = 1515870810, skipwhite = 1515870810, baseURI = 0x5a5a5a5a } [2005-03-09 08:07:06] MageOfChrisz at Gmail dot com Description: (Most of what I say here can be found at http://chrisallan.info/segfault/) When putting "xml_parser_free" in a function assigned to the XML parser with xml_set_element_handler, Apache/PHP Gives a Segmentation Fault. The only browser that you can feasibly see it blow up, would be in lynx. In FireFox, if you're at www.google.com and type in the link to the file (http://chrisallan.info/segfault/function_example.php) it will still show google.com and fail to load the new page. A similar result occurs with Internet Explorer, but in Lynx it'll say: "Alert!: Unexpected Network read error; connection aborted;" I made a PHP5.0.4-dev build (as of Mar 09, 2005 05:30 GMT) from snaps.php.net. This was originally discovered in PHP 5.0.3, and then tested in PHP5.0.4-dev Reproduce code: --- You can find the code (neatly) here: http://chrisallan.info/segfault/ Expected result: Some sort of error telling me not to do what I was doing (due to lack of sleep) or the xml resource actually being freed Actual result: -- Segmentation Fault -- Edit
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866 Updated by: [EMAIL PROTECTED] Reported By: kevin at hatry dot com Status: Bogus Bug Type: MySQL related Operating System: windows XP + linux PHP Version: 4.3.11 New Comment: Please don't abuse the bug system for questions and discussions. Use PHP's mailinglists (http://www.php.net/mailing-lists.php) Previous Comments: [2005-04-28 13:48:26] kevin at hatry dot com thank you for your direct answer however this "solution" cannot work with a heavily loaded website as it would open too much connections on the mysql server : for example a page called 50 times a second and opening 3 connections at a the same time means 150 connections /sec to the mysql server instead of 50 ! This situation is clearly one where the shared connection is useful. i will try one last example to make sure you really know how i "want it to work", please read it through and answer the last question below, thank you. the following script (without any function to make it clearer) : generate this output : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (Unknown) Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ... on line 24 mysql thread : Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on line 28 If you could please answer this one last question : why does affecting "NULL" to $link1 make $link2 to become "Unkown" ? In other words, why don't we see this output instead : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (mysql link) mysql thread : 16 If this is a feature than it should be documented as it is not obvious that changing the value of the resource variable will close the connection, even if it has been closed before. [2005-04-28 12:49:42] [EMAIL PROTECTED] Change false to true in mysql_connect() and it will work like you want it to work. Still not a bug. [2005-04-28 12:26:33] kevin at hatry dot com Description: I originally posted this info on follow up of bug id 30525 but it has been reported as bogus and i dont think the problem has been fully understood. Please *do* try to understand the problem here as there *is* one ! PHP version used : -> php 4.3.11 on win32 with the bundled 3.23.49 mysql client -> php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client both with apache 1.3.33 and with the cli binary. Preface : I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links but that there now appears to be reference counting before finally closing the TCP connection which is a better thing for me. The problem is : It seems that affecting a value or 'unset'ing a variable of type mysql resource or living the function in which the variable was created calls mysql_close on that variable (and so reduces the reference) even if a previous call was already made on that variable. So the reference count becomes wrong. So it is very hard to keep track of the real status (connected, not connected, of type mysql, of type unknown) of a mysql resource. The reproduce code is quite simple but is, i think, a typical way of programming : you have a function (or class) that query mysql by creating its own resource. Normally, with this version of PHP, the call to mysql_close should not close the shared connection so the code is ok to use. But with the bug a second call to mysl_close is made when the function returns. A last note : the same bug can be found if, instead of calling the function "do_something_in_mysql" we do $link1 = -1; after the line "mysql_close($link1);". Thank you for your time, i hope you will see the bug this time. Reproduce code: --- the bug. echo "link1 : "; var_dump($link1); echo "link2 : "; var_dump($link2); function do_something_in_mysql () { $link3 = mysql_connect('localhost','root','',false); echo "link3 : "; var_dump($link3); // do some common queries here mysql_close($link3); } ?> Expected result: link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) link3 : resource(4) of type (mysql link) link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) because $link2 has not been explicitly clo
#32852 [Opn->Fbk]: Crash with singleton and __destruct
ID: 32852 Updated by: [EMAIL PROTECTED] Reported By: cox at idecnet dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: I still can't reproduce this. I get same result with both HEAD and PHP_5_0 branches and also with the snapshot. Does it give same result if you make sure you don't load any php.ini: sapi/cli/php -n file.php What bison version do you have installed? What compiler (and version) ? Previous Comments: [2005-04-28 10:53:13] cox at idecnet dot com With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache && ./configure + your options + --enable-debug && make clean && make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' [2005-04-27 14:41:26] [EMAIL PROTECTED] For some reason it doesn't crash for me..did you use --enable-debug ? 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/32852 -- Edit this bug report at http://bugs.php.net/?id=32852&edit=1
#32866 [Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866 User updated by: kevin at hatry dot com Reported By: kevin at hatry dot com Status: Bogus Bug Type: MySQL related Operating System: windows XP + linux PHP Version: 4.3.11 New Comment: thank you for your direct answer however this "solution" cannot work with a heavily loaded website as it would open too much connections on the mysql server : for example a page called 50 times a second and opening 3 connections at a the same time means 150 connections /sec to the mysql server instead of 50 ! This situation is clearly one where the shared connection is useful. i will try one last example to make sure you really know how i "want it to work", please read it through and answer the last question below, thank you. the following script (without any function to make it clearer) : generate this output : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (Unknown) Warning: mysql_thread_id(): 4 is not a valid MySQL-Link resource in ... on line 24 mysql thread : Warning: mysql_query(): 4 is not a valid MySQL-Link resource in ... on line 28 If you could please answer this one last question : why does affecting "NULL" to $link1 make $link2 to become "Unkown" ? In other words, why don't we see this output instead : link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after closing link1 : link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) mysql thread : 16 -- after link1 = NULL : link1 : NULL link2 : resource(4) of type (mysql link) mysql thread : 16 If this is a feature than it should be documented as it is not obvious that changing the value of the resource variable will close the connection, even if it has been closed before. -- Edit this bug report at http://bugs.php.net/?id=32866&edit=1
#32865 [Opn->Bgs]: explode do not works with $limit = null
ID: 32865 Updated by: [EMAIL PROTECTED] Reported By: dan at yes dot lt -Status: Open +Status: Bogus Bug Type: Strings related Operating System: WinXP PHP Version: 5.0.4 New Comment: No, it's how the language works. Previous Comments: [2005-04-28 13:06:47] dan at yes dot lt now I have to write.. if ($lim === null) { $parts = explode(',', $str); } else { $parts = explode(',', $str, $lim); } ..instead of.. $parts = explode(',', $str, $lim); Isn't it some sort of crap ?.. [2005-04-28 12:09:12] dan at yes dot lt So what should I give to $limit to explode unlimited ???... As I know - in PHP no parameter means some default value - what default value is defined to default $limit ?.. [2005-04-28 11:43:01] [EMAIL PROTECTED] Yes, null == 0. (PHP is still loose typed language..) [2005-04-28 11:19:04] dan at yes dot lt Description: explode() do not explodes string if $limit argument is null, but explodes if no $limit argument given. Reproduce code: --- print_r(explode(',', 'a,b,c')); print_r(explode(',', 'a,b,c', null)); Expected result: Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a [1] => b [2] => c ) Actual result: -- Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a,b,c ) -- Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#32865 [Bgs->Opn]: explode do not works with $limit = null
ID: 32865 User updated by: dan at yes dot lt Reported By: dan at yes dot lt -Status: Bogus +Status: Open Bug Type: Strings related Operating System: WinXP PHP Version: 5.0.4 New Comment: now I have to write.. if ($lim === null) { $parts = explode(',', $str); } else { $parts = explode(',', $str, $lim); } ..instead of.. $parts = explode(',', $str, $lim); Isn't it some sort of crap ?.. Previous Comments: [2005-04-28 12:09:12] dan at yes dot lt So what should I give to $limit to explode unlimited ???... As I know - in PHP no parameter means some default value - what default value is defined to default $limit ?.. [2005-04-28 11:43:01] [EMAIL PROTECTED] Yes, null == 0. (PHP is still loose typed language..) [2005-04-28 11:19:04] dan at yes dot lt Description: explode() do not explodes string if $limit argument is null, but explodes if no $limit argument given. Reproduce code: --- print_r(explode(',', 'a,b,c')); print_r(explode(',', 'a,b,c', null)); Expected result: Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a [1] => b [2] => c ) Actual result: -- Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a,b,c ) -- Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream
ID: 28074 Updated by: [EMAIL PROTECTED] Reported By: bogus_idp at yahoo dot fr -Status: Open +Status: Assigned Bug Type: CGI related Operating System: * PHP Version: 4CVS, 5CVS (2005-01-10) -Assigned To: +Assigned To: sas New Comment: Feel free to fix it then. Previous Comments: [2005-04-21 11:43:51] [EMAIL PROTECTED] This is an ugly change for users who redirect PHP's stderr to a log file due to file permissions (PHP is not allowed to open the log file). Instead of writing to the log file, the Apache log now contains tons of rows like this: [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: array ( [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: 'rcs' => [Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI: server "/home/www/PHP/php/bin/php" stderr: array ( etc. This needs to be addressed -- make logging to fastcgi's stderr optional. [2005-01-10 16:01:29] chris at ex-parrot dot com This one turns out to be easy to fix, thus: --- cgi_main.c.orig Mon Jan 10 14:57:04 2005 +++ cgi_main.c Mon Jan 10 14:53:44 2005 @@ -481,7 +481,14 @@ static void sapi_cgi_log_message(char *message) { - fprintf(stderr, "%s\n", message); +#if PHP_FASTCGI +if (!FCGX_IsCGI()) { +FCGX_Request *request = (FCGX_Request *)SG(server_context); +FCGX_FPrintF( request->err, "%s\n", message ); +/* ignore return code */ +} else +#endif /* PHP_FASTCGI */ + fprintf(stderr, "%s\n", message); } static int sapi_cgi_deactivate(TSRMLS_D) However, there is another similar bug, which is that a stream opened on "php://stderr" should also direct its output to the FCGI error stream (rather than just to file descriptor #2). -- Chris Lightfoot [2004-04-20 12:03:30] bogus_idp at yahoo dot fr Description: The Fast CGI standard require that error be reported through the FastCGI connection as a Stderr data stream. But PHP Fast CGI processes still write errors to original stderr (file handle 3) which prevent from clean standard centralized FCGI logging, especially when the Fast CGI PHP process is not started by the web server (remote Fast CGI). In most cases, it makes debugging PHP scripts impossible. -- Edit this bug report at http://bugs.php.net/?id=28074&edit=1
#31222 [Opn->Fbk]: ocicommit not working
ID: 31222 Updated by: [EMAIL PROTECTED] Reported By: amonw at hotmail dot com -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2005-04-04 Assigned To: tony2001 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Previous Comments: [2005-04-26 04:20:18] amonw at hotmail dot com I don't know why, but I upgrate my php again this morning to php4-stable-200504260035, and the problem remains unchanged. I have make the code as simple as possible, and as I mentioned in the first comment, even some minor changes which seem not relevant may affect the result, and I don't know why. I deeply appreciate your patiense and please read my first post again. I can live with it if you are tired of this because it takes so long. Thank you. [2005-04-05 17:55:52] [EMAIL PROTECTED] Works just perfectly for all of oci8 users except you. Try to simplify the code and to look for the problem there. [2005-04-04 09:27:40] amonw at hotmail dot com I tried the http://snaps.php.net/php4-STABLE-latest.tar.gz,which extracted to be php4-STABLE-200504040230,but the code produced the same result. [2005-03-30 23:06:56] [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 [2004-12-24 03:08:50] amonw at hotmail dot com Thank you for your help. But can you explain why the 4 methods I listed in the first comment can change the result? And why can't I add "ocilogoff($c)" before the second ocilogon to change the result? 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/31222 -- Edit this bug report at http://bugs.php.net/?id=31222&edit=1
#32867 [Opn->Bgs]: ini_set has no effect for magic_quotes_gpc
ID: 32867 Updated by: [EMAIL PROTECTED] Reported By: Arne dot Heizmann at csr dot com -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Windows 2000 PHP Version: 4.3.11 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. By the time that ini_set() call is run, the request data is already processed. Previous Comments: [2005-04-28 12:46:05] Arne dot Heizmann at csr dot com Description: I have tried ini_set ('magic_quotes_gpc', 0); and ini_set ('magic_quotes_gpc', 'Off'); and various others, but I still get those stupid backslashes. Reproduce code: --- ini_set ('magic_quotes_gpc', 0); echo ''. get_array_val ('x', $_POST) . ''; echo " "; Expected result: Upon submitting the form, you should see an apostrophe. Actual result: -- You see a backslash followed by an apostrophe. -- Edit this bug report at http://bugs.php.net/?id=32867&edit=1
#32866 [Opn->Bgs]: implicit (and redundant) mysql_close on mysql resource destruction
ID: 32866 Updated by: [EMAIL PROTECTED] Reported By: kevin at hatry dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: windows XP + linux PHP Version: 4.3.11 New Comment: Change false to true in mysql_connect() and it will work like you want it to work. Still not a bug. Previous Comments: [2005-04-28 12:26:33] kevin at hatry dot com Description: I originally posted this info on follow up of bug id 30525 but it has been reported as bogus and i dont think the problem has been fully understood. Please *do* try to understand the problem here as there *is* one ! PHP version used : -> php 4.3.11 on win32 with the bundled 3.23.49 mysql client -> php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client both with apache 1.3.33 and with the cli binary. Preface : I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links but that there now appears to be reference counting before finally closing the TCP connection which is a better thing for me. The problem is : It seems that affecting a value or 'unset'ing a variable of type mysql resource or living the function in which the variable was created calls mysql_close on that variable (and so reduces the reference) even if a previous call was already made on that variable. So the reference count becomes wrong. So it is very hard to keep track of the real status (connected, not connected, of type mysql, of type unknown) of a mysql resource. The reproduce code is quite simple but is, i think, a typical way of programming : you have a function (or class) that query mysql by creating its own resource. Normally, with this version of PHP, the call to mysql_close should not close the shared connection so the code is ok to use. But with the bug a second call to mysl_close is made when the function returns. A last note : the same bug can be found if, instead of calling the function "do_something_in_mysql" we do $link1 = -1; after the line "mysql_close($link1);". Thank you for your time, i hope you will see the bug this time. Reproduce code: --- the bug. echo "link1 : "; var_dump($link1); echo "link2 : "; var_dump($link2); function do_something_in_mysql () { $link3 = mysql_connect('localhost','root','',false); echo "link3 : "; var_dump($link3); // do some common queries here mysql_close($link3); } ?> Expected result: link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) link3 : resource(4) of type (mysql link) link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) because $link2 has not been explicitly closed the reference count should be of 1 instead of 0 (there was 3 calls to mysql_connect and only 2 calls to mysql_close) and link2 should still be usable. Actual result: -- link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) link3 : resource(4) of type (mysql link) link1 : resource(4) of type (Unknown) link2 : resource(4) of type (Unknown) $link2 is no longer a mysql resource and the TCP connection to the mysql server is lost although there was 3 calls to mysql_connect and only 2 explicit calls to mysql_close. -- Edit this bug report at http://bugs.php.net/?id=32866&edit=1
#32867 [NEW]: ini_set has no effect for magic_quotes_gpc
From: Arne dot Heizmann at csr dot com Operating system: Windows 2000 PHP version: 4.3.11 PHP Bug Type: PHP options/info functions Bug description: ini_set has no effect for magic_quotes_gpc Description: I have tried ini_set ('magic_quotes_gpc', 0); and ini_set ('magic_quotes_gpc', 'Off'); and various others, but I still get those stupid backslashes. Reproduce code: --- ini_set ('magic_quotes_gpc', 0); echo ''. get_array_val ('x', $_POST) . ''; echo " "; Expected result: Upon submitting the form, you should see an apostrophe. Actual result: -- You see a backslash followed by an apostrophe. -- Edit bug report at http://bugs.php.net/?id=32867&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32867&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32867&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32867&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32867&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32867&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32867&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32867&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32867&r=support Expected behavior: http://bugs.php.net/fix.php?id=32867&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32867&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32867&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32867&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32867&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32867&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32867&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32867&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32867&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32867&r=mysqlcfg
#32866 [NEW]: implicit (and redundant) mysql_close on mysql resource destruction
From: kevin at hatry dot com Operating system: windows XP + linux PHP version: 4.3.11 PHP Bug Type: MySQL related Bug description: implicit (and redundant) mysql_close on mysql resource destruction Description: I originally posted this info on follow up of bug id 30525 but it has been reported as bogus and i dont think the problem has been fully understood. Please *do* try to understand the problem here as there *is* one ! PHP version used : -> php 4.3.11 on win32 with the bundled 3.23.49 mysql client -> php 4.3.11 on linux kernel 2.4.29 with external 4.1.11 mysql client both with apache 1.3.33 and with the cli binary. Preface : I *do* understand that by default MySQL connections are shared in PHP. I also note that in older versions a single mysql_close() would close all of the links but that there now appears to be reference counting before finally closing the TCP connection which is a better thing for me. The problem is : It seems that affecting a value or 'unset'ing a variable of type mysql resource or living the function in which the variable was created calls mysql_close on that variable (and so reduces the reference) even if a previous call was already made on that variable. So the reference count becomes wrong. So it is very hard to keep track of the real status (connected, not connected, of type mysql, of type unknown) of a mysql resource. The reproduce code is quite simple but is, i think, a typical way of programming : you have a function (or class) that query mysql by creating its own resource. Normally, with this version of PHP, the call to mysql_close should not close the shared connection so the code is ok to use. But with the bug a second call to mysl_close is made when the function returns. A last note : the same bug can be found if, instead of calling the function "do_something_in_mysql" we do $link1 = -1; after the line "mysql_close($link1);". Thank you for your time, i hope you will see the bug this time. Reproduce code: --- the bug. echo "link1 : "; var_dump($link1); echo "link2 : "; var_dump($link2); function do_something_in_mysql () { $link3 = mysql_connect('localhost','root','',false); echo "link3 : "; var_dump($link3); // do some common queries here mysql_close($link3); } ?> Expected result: link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) link3 : resource(4) of type (mysql link) link1 : resource(4) of type (Unknown) link2 : resource(4) of type (mysql link) because $link2 has not been explicitly closed the reference count should be of 1 instead of 0 (there was 3 calls to mysql_connect and only 2 calls to mysql_close) and link2 should still be usable. Actual result: -- link1 : resource(4) of type (mysql link) link2 : resource(4) of type (mysql link) link3 : resource(4) of type (mysql link) link1 : resource(4) of type (Unknown) link2 : resource(4) of type (Unknown) $link2 is no longer a mysql resource and the TCP connection to the mysql server is lost although there was 3 calls to mysql_connect and only 2 explicit calls to mysql_close. -- Edit bug report at http://bugs.php.net/?id=32866&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32866&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32866&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32866&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32866&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32866&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32866&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32866&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32866&r=support Expected behavior: http://bugs.php.net/fix.php?id=32866&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32866&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32866&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32866&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32866&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32866&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32866&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32866&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32866&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32866&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32866&r=mysqlcfg
#32865 [Bgs]: explode do not works with $limit = null
ID: 32865 User updated by: dan at yes dot lt Reported By: dan at yes dot lt Status: Bogus Bug Type: Strings related Operating System: WinXP PHP Version: 5.0.4 New Comment: So what should I give to $limit to explode unlimited ???... As I know - in PHP no parameter means some default value - what default value is defined to default $limit ?.. Previous Comments: [2005-04-28 11:43:01] [EMAIL PROTECTED] Yes, null == 0. (PHP is still loose typed language..) [2005-04-28 11:19:04] dan at yes dot lt Description: explode() do not explodes string if $limit argument is null, but explodes if no $limit argument given. Reproduce code: --- print_r(explode(',', 'a,b,c')); print_r(explode(',', 'a,b,c', null)); Expected result: Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a [1] => b [2] => c ) Actual result: -- Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a,b,c ) -- Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. Previous Comments: [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. [2005-04-27 23:20:34] ast at gmx dot ch Obviously, the bug report was mangled. Here's a pretty print of the report / fix: http://nei.ch/articles/quoted_string_cookie_fix.php [2005-04-27 21:46:18] ast at gmx dot ch Description: /* * Description: *RFC 2965 describes the HTTP State Management mechanism. *From section "3.1 Syntax: General": * av-pairs= av-pair *(";" av-pair) * av-pair = attr ["=" value] ; optional value * attr= token * value = token | quoted-string * *PHP 4.3.11 does not handle the case of "quoted-string" values. *See RFC 2616 section "2.2 Basic Rules" for a definition of "quoted-string". *quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) *qdtext = > * * The backslash character ("\") MAY be used as a single-character * quoting mechanism only within quoted-string and comment constructs. * *quoted-pair= "\" CHAR * *PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore, it can handle *values that contain the separators "," and ";". But the RFC 2965 describes that *a HTTP Cookie header sent from the user agent to the server may have av-pairs, *where the value may be a token or a quoted string. * *If one sets a cookie not with PHP's setCookie() method, but directly with header(), *then it is sent correctly to the user agent and the user agent returns it also *correctly. But when PHP reads the HTTP Cookie header back into $_COOKIE, it does *not handle quoted-strings. * *Result: * Wrong cookie values in $_COOKIE. * *The bug is in PHP's source in function * SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data) *It parses the HTTP Cookie header and directly uses "," and ";" as separators. *A slightly more complicated handling of the HTTP Cookie header is required. *In addition to the current code, one has to handle: * - quoted-strings: separators "," and ";" may be in quoted-strings * - double-quote marks escaped by "\" don't end a quoted-string * *Cookies with values that are not urlencoded may come from: * - non-PHP applications on the same host * - RFC 2965 compliant PHP cookies that were set with header() instead of setcookie(). * *Example: * In PHP script: *header('Set-Cookie: TestCookie = "value with , perfectly ; allowed 8-Bit characters ' . *'and escaped \" double-quote marks!"'); * The cookie is successfully sent to the user agent. The user agent sends it back with a * perfectly intact value. * PHP receives the HTTP Cookie header from the webserver (I inserted the line break): *Cookie: TestCookie="value with , perfectly ; allowed 8-Bit characters and escaped \" *double-quote marks!"\r\n * Then PHP parses the HTTP Cookie header ignoring the case of quoted-strings and fills the * superglobal $_COOKIE with: * ["TestCookie"]=> *string(24) ""value with , perfectly " * ["allowed_8-BIT_characters_and_escaped_\"_double-quote_marks!""]=> *string(0) "" * If PHP handled the HTTP Cookie header correctly, one would ge
#32789 [Bgs]: array_pop doesn't work correctly
ID: 32789 User updated by: php at thoftware dot de Reported By: php at thoftware dot de Status: Bogus Bug Type: Arrays related Operating System: * PHP Version: 4.3.11 New Comment: I don't know, who is deleting my submissions, but I think it would be better to delete the whole thread instead of deleting only some submissions which makes the references in other submissions nonsense. I accept that you don't accept this as a bug and I wont post any new found bugs as it seems to be easyer to handle with bugs than to get a bug reported. Nice job. Previous Comments: [2005-04-26 14:08:02] php at thoftware dot de Looks like nobody is listening here - sigh. After discussing this in another forum, we are still sure this _is_ a bug. As I was ordered not to set this bug back to open we are trying to start over with a new bug-report in a new location (it's not really a bug in array_pop() but something in the reference system). Someone with a hopefully better ability to explain where the bug is located will post it and I will add a link to it afterwards - hope that's o.k. [2005-04-25 22:18:30] php at thoftware dot de Maybe this one from Waq explains it in a better way why I think it's a bug: http://www.php.de/viewtopic.php?p=252840#252840 (it's from a german forum where the people tried to understand what I tried to say). I didn't ask for help, the script that crashed because of this bogus bug was already fixed when I submitted this. Sorry for taking your time, surely PHP acts perfect in this case :-( P.S. Why are you deleting your comments? Do you think it makes it even more bogus when it looks like I'm talking to myself? Not nice :-( [2005-04-23 09:05:35] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. bugs is not a helpdesk - please leave this as bogus and ask on php-general. [2005-04-22 15:56:37] php at thoftware dot de Sorry again, maybe I should stop coding %-(, this is the real Actual result: -- it's forever mine noone else should be able to change it it's mine this is my cache for the example directly above ... [2005-04-22 15:54:09] php at thoftware dot de Sorry, the fatal error results from the result of cache() being an empty array (but that may be another bug?), correct code should be: Reproduce code: --- class foobar { var $cache = array(); function cache() { if (!count($this->cache)) { $this->cache[1] = array( 'this is my cache', 'it\'s mine', 'noone else should be able to change it', 'it\'s forever mine', ); } return($this->cache[1]); } } $foobar =& new foobar(); echo array_pop($foobar->cache()); echo array_pop($foobar->cache()); echo array_pop($foobar->cache()); echo array_pop($foobar->cache()); Expected result: it's forever mine it's forever mine it's forever mine it's forever mine Actual result: -- Fatal error: Only variables can be passed by reference in ... Using a static variable within the method will work like the example using a plain function, using an object-variable will work like shown above, even if you remove the '[1]'-part. 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/32789 -- Edit this bug report at http://bugs.php.net/?id=32789&edit=1
#32865 [NEW]: explode do not works with $limit = null
From: dan at yes dot lt Operating system: WinXP PHP version: 5.0.4 PHP Bug Type: *General Issues Bug description: explode do not works with $limit = null Description: explode() do not explodes string if $limit argument is null, but explodes if no $limit argument given. Reproduce code: --- print_r(explode(',', 'a,b,c')); print_r(explode(',', 'a,b,c', null)); Expected result: Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a [1] => b [2] => c ) Actual result: -- Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a,b,c ) -- Edit bug report at http://bugs.php.net/?id=32865&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32865&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32865&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32865&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32865&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32865&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32865&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32865&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32865&r=support Expected behavior: http://bugs.php.net/fix.php?id=32865&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32865&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32865&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32865&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32865&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32865&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32865&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32865&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32865&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32865&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32865&r=mysqlcfg
#32865 [Opn->Bgs]: explode do not works with $limit = null
ID: 32865 Updated by: [EMAIL PROTECTED] Reported By: dan at yes dot lt -Status: Open +Status: Bogus -Bug Type: *General Issues +Bug Type: Strings related Operating System: WinXP PHP Version: 5.0.4 New Comment: Yes, null == 0. (PHP is still loose typed language..) Previous Comments: [2005-04-28 11:19:04] dan at yes dot lt Description: explode() do not explodes string if $limit argument is null, but explodes if no $limit argument given. Reproduce code: --- print_r(explode(',', 'a,b,c')); print_r(explode(',', 'a,b,c', null)); Expected result: Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a [1] => b [2] => c ) Actual result: -- Array ( [0] => a [1] => b [2] => c ) Array ( [0] => a,b,c ) -- Edit this bug report at http://bugs.php.net/?id=32865&edit=1
#32841 [Asn->WFx]: returned a member variable cannot be turned into reference
ID: 32841 Updated by: [EMAIL PROTECTED] Reported By: wagner at bonn dot edu -Status: Assigned +Status: Wont fix Bug Type: Scripting Engine problem Operating System: * PHP Version: 4.3.11, 5.0.4 Assigned To: andi New Comment: What you are trying to do is feasable in different ways. - just not the way you are trying.. (try the support channels for suggestions.) - whether what you are trying to do is a good idea (maintance, code readability, creating bugs) is another question... changing the engine behavior to do what you say is extremely complex. And the return on fixing this would not be worth the instability that it would involve (we know from previous efforts at looking at this). hint: use return &$this->var; $tmp = &$foo->f_default(); incr($tmp); Previous Comments: [2005-04-28 06:34:50] wagner at bonn dot edu > In your case f_default() returns *copy*, not a reference No it doesn't. Try this as case 1 in the reproduce code as above: -- case 1: //forced reference works AND makes default behaviour //work afterwards echo incr($foo->f_ref())."\n"; echo incr($foo->f_default())."\n"; echo incr($foo->f_default())."\n"; break; Expected result: 1 2 2 f_default() should return a copy Actual result: -- 1 2 3 incr() gets a reference to $foo->v and modifies it Since I filed this behaviour as another bug here http://bugs.php.net/bug.php?id=32840 could it please be looked at too and be unbogusified? [2005-04-27 23:45:04] [EMAIL PROTECTED] Short version: this is expected and the error message clearly says why: only variables can be referenced and you cannot make a reference to an expression result. Long version: In your case f_default() returns *copy*, not a reference as you wrongly consider, while f_ref() returns reference and should work indeed. But I'm a bit surprised to see that f_copy() works, as it should give the same warning as with f_default(). Concerning the case 2, AFAIK it's because of some reference magic: when you return $this->v as reference, it turns in refernce itself (refcount++) and the following call to f_default() returns this reference. Though, it would be interesting to see what engine gurus say about it. [2005-04-26 14:54:41] wagner at bonn dot edu Description: When returning a member-variable directly as a reference parameter into a function, a fatal error occurs: Fatal error: Only variables can be passed by reference ... The reproduce code displays the bug (for $case=0) as well as two simple workarounds that IMHO show that the ZEND-Engine should be able to handle this with no need for any error. This seems to have been around for a while, at least PHP 4.3.x Probably related to http://bugs.php.net/bug.php?id=32840 Reproduce code: --- $case = 0; function incr(&$int) { return $int++; } class foo { var $v = 1; function &f_ref() { return $this->v; } function f_copy() { return (int)$this->v; } //forced copy through type-cast function f_default() { return $this->v; } } $foo =& new foo(); switch($case) { case 0: //default behaviour is broken echo incr($foo->f_default())."\n"; case 1: //forced reference works AND makes default behaviour work afterwards echo incr($foo->f_ref())."\n"; echo incr($foo->f_default())."\n"; break; case 2: //forced copy works echo incr($foo->f_copy())."\n"; break; } Expected result: incr() should get a copy of $foo->v Actual result: -- Fatal error: Only variables can be passed by reference in foo.php on line 19 -- Edit this bug report at http://bugs.php.net/?id=32841&edit=1
#32852 [Fbk->Opn]: Crash with singleton and __destruct
ID: 32852 User updated by: cox at idecnet dot com Reported By: cox at idecnet dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.0.4 New Comment: With today's CVS (5.1), it does not crash. But the output is: Output: i'm called i'm called i'm called i'm called The __destruct() function is called 4 times. With php5-STABLE-200504271035 (5.0.5dev): $ make distclean $ ./configure \ --prefix=/usr \ --with-config-file-path=/etc/php5 \ --enable-cli \ --disable-cgi \ --disable-pear \ --enable-debug Still the same output and same crash. Previous Comments: [2005-04-28 00:25:57] [EMAIL PROTECTED] If you configure with --enable-debug (rm config.cache && ./configure + your options + --enable-debug && make clean && make) does it still crash? Are you sure you ARE using the latest CVS? (the snapshots might not be updated again..) [2005-04-27 23:25:44] [EMAIL PROTECTED] Still works fine here. Both with HEAD and 5.0.x. [2005-04-27 16:52:39] cox at idecnet dot com Versions and compile options for the two that crashes for me. In case it says something for you, if I remove the __destructor() function the code works good (also you see in the output this function is being called twice). 5.0.4 ~~~ PHP 5.0.4 (cli) (built: Apr 27 2005 11:48:13) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' 5.0.5 Snapshot Stable ~~~ PHP 5.0.5-dev (cli) (built: Apr 27 2005 13:47:32) (DEBUG) Configure Command => './configure' '--prefix=/usr' '--with-config-file-path=/etc/php5' '--with-xml' '--with-zlib' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-png-dir' '--with-jpeg-dir' '--disable-pear' '--with-mysql=/usr' '--with-imap=/usr/include/imap' '--with-imap-ssl' '--with-kerberos' '--with-gettext' '--enable-ftp' '--with-dom' '--with-mhash' '--with-mcrypt' '--enable-cli' '--enable-sockets' '--enable-sigchild' '--enable-pcntl' '--enable-shmop' '--enable-posix' '--enable-bcmath' '--with-xmlrpc' '--with-mime-magic' '--disable-cgi' '--enable-debug' [2005-04-27 14:41:26] [EMAIL PROTECTED] For some reason it doesn't crash for me..did you use --enable-debug ? [2005-04-27 14:10:28] cox at idecnet dot com I'm not very expert on gdb usage. Please tell me if you need extra info. $ gdb /usr/bin/php5.0.5dev core.31085 GNU gdb 6.0-2mdk (Mandrake Linux) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/usr/bin/php5.0.5dev test.php'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/lib/libmysqlclient.so.12...done. Loaded symbols for /usr/lib/libmysqlclient.so.12 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /usr/lib/libmhash.so.2...done. Loaded symbols for /usr/lib/libmhash.so.2 Reading symbols from /usr/lib/libmcrypt.so.4...done. Loaded symbols for /usr/lib/libmcrypt.so.4 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading
#30578 [Opn->Csd]: Output buffers flush explicitly before all variables have gone out of scope
ID: 30578 Updated by: [EMAIL PROTECTED] Reported By: anthony at ectrolinux dot com -Status: Open +Status: Closed Bug Type: Output Control Operating System: * PHP Version: 5CVS-2005-03-07 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fix will be in PHP 5.1 Previous Comments: [2004-10-27 08:09:59] anthony at ectrolinux dot com Description: During script termination, PHP's explicit output buffer flush should wait until all variables have gone -completely- out of scope. Using an instantiated object that manages buffers, the data has already been flushed before __destruct() is called, which prevents the script from properly finalizing data collection and flushing the output normally. This is not the appropriate behavior. Reproduce code: --- Expected result: This should be displayed first. Buffered data: This should be displayed last. Actual result: -- This should be displayed last. Notice: ob_end_clean(): failed to delete buffer. No buffer to delete. in /--snip--/test.php on line 17 This should be displayed first. Buffered data: -- Edit this bug report at http://bugs.php.net/?id=30578&edit=1
#32844 [Opn->Bgs]: libphp4.so not created
ID: 32844 Updated by: [EMAIL PROTECTED] Reported By: adam at adamandliz dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Fedora Core 2 PHP Version: 4.3.11 New Comment: No bug -> bogus. Previous Comments: [2005-04-28 09:04:18] adam at adamandliz dot com my apologies... I had previously found advice on other pages that uses libtoolize Anyway, I deleted the directory and re-created from the tar (4.3.11) the .so gets created this time. [2005-04-28 00:15:36] [EMAIL PROTECTED] You did use fresh sources? And you are not doing something silly like running buildconf or autoconf or libtoolize..? [2005-04-27 18:17:29] adam at adamandliz dot com Still no .so created, only a .a and .la additionally, the following messages appeared in the make using piecewise archive linking... /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected (last message repeated dozens of times) [2005-04-27 12:54:51] [EMAIL PROTECTED] Try with this configure line: # ./configure --disable-all --with-apxs2=/usr/local/apache2/bin/apxs [2005-04-26 18:29:17] adam at adamandliz dot com Description: Firstly, I have no problems under 4.3.9. However 4.3.10, 4.3.11 and a recent snapshot fail. Whenc ompiling php using standard ./configure, make, make install. the libphp4.so file is not created. the configure command is: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr/local/mysql --with-config-file-path=/usr/local/lib/php -with-imap --enable-mbstring --with-kerberos --with-imap-ssl Before the last libtool in the make command, the following is displayed (this may well be ared herring) *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. When doing a make install, I get (from the recent snapshot): [EMAIL PROTECTED] php4-STABLE-200504251836]# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a ranlib /usr/local/apache2/modules/libphp4.a chmod 644 /usr/local/apache2/modules/libphp4.a libtool: install: warning: remember to run `libtool --finish /usr/php4-STABLE-200504251836/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp4.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp4.so chmod: cannot access `/usr/local/apache2/modules/libphp4.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/?id=32844&edit=1
#32844 [Fbk->Opn]: libphp4.so not created
ID: 32844 User updated by: adam at adamandliz dot com Reported By: adam at adamandliz dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Fedora Core 2 PHP Version: 4.3.11 New Comment: my apologies... I had previously found advice on other pages that uses libtoolize Anyway, I deleted the directory and re-created from the tar (4.3.11) the .so gets created this time. Previous Comments: [2005-04-28 00:15:36] [EMAIL PROTECTED] You did use fresh sources? And you are not doing something silly like running buildconf or autoconf or libtoolize..? [2005-04-27 18:17:29] adam at adamandliz dot com Still no .so created, only a .a and .la additionally, the following messages appeared in the make using piecewise archive linking... /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected /usr/php-4.3.11/libtool: line 5386: test: : integer expression expected (last message repeated dozens of times) [2005-04-27 12:54:51] [EMAIL PROTECTED] Try with this configure line: # ./configure --disable-all --with-apxs2=/usr/local/apache2/bin/apxs [2005-04-26 18:29:17] adam at adamandliz dot com Description: Firstly, I have no problems under 4.3.9. However 4.3.10, 4.3.11 and a recent snapshot fail. Whenc ompiling php using standard ./configure, make, make install. the libphp4.so file is not created. the configure command is: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr/local/mysql --with-config-file-path=/usr/local/lib/php -with-imap --enable-mbstring --with-kerberos --with-imap-ssl Before the last libtool in the make command, the following is displayed (this may well be ared herring) *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. When doing a make install, I get (from the recent snapshot): [EMAIL PROTECTED] php4-STABLE-200504251836]# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a ranlib /usr/local/apache2/modules/libphp4.a chmod 644 /usr/local/apache2/modules/libphp4.a libtool: install: warning: remember to run `libtool --finish /usr/php4-STABLE-200504251836/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp4.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp4.so chmod: cannot access `/usr/local/apache2/modules/libphp4.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/?id=32844&edit=1