#41119 [Opn-Csd]: range() function behavior different on PHP6 and PHP5
ID: 41119 Updated by: [EMAIL PROTECTED] Reported By: mahesh dot vemula at in dot ibm dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: RHEL 4 PHP Version: 6CVS-2007-04-17 (snap) New Comment: Works fine on PHP 6.0.0-dev (cli) (built: Jan 14 2008 08:38:52) Previous Comments: [2007-04-17 13:48:03] mahesh dot vemula at in dot ibm dot com Description: Output of PHP5 and PHP6 differ for range() function. The difference appears when an empty string() is given as low value and FLOAT as high value. PHP5 gives the consistent output for an empty string and normal string, which is an array of float elements. Whereas PHP6 treats empty and normal strings differently when high value is a FLOAT. The output of range() with an empty string() as low value is array of Integer elements and with regular string as low value is array of float elements. Environment: Operating System: RHEL 4 Linux Kernel : Linux 2.6.9 PHP Version: PHP 5.2 (Built on Apr 17, 2007 from snaps.php.net) PHP Configure Setup: ./configure Reproduce code: --- ?php var_dump( range(, 2.2) ); var_dump( range(string, 2.2) ); ? Expected result: array(3) { [0]= float(0) [1]= float(1) [2]= float(2) } array(3) { [0]= float(0) [1]= float(1) [2]= float(2) } Actual result: -- PHP5 gives the output as expected but PHP6 gives the following output: array(3) { [0]= int(0) [1]= int(1) [2]= int(2) } array(3) { [0]= float(0) [1]= float(1) [2]= float(2) } -- Edit this bug report at http://bugs.php.net/?id=41119edit=1
#43838 [NEW]: variant_set with IE leads to hang
From: csaba at alum dot mit dot edu Operating system: Win XP Pro PHP version: 5.2.5 PHP Bug Type: COM related Bug description: variant_set with IE leads to hang Description: If an event sink is set on IE, and then a new window is created by that IE (by clicking on a link with target=_blank, say), then NewWindow2 fires. By replacing the first argument to NewWindow2 (via set_variant) it is possible to identify the pending new ie and to assign a sink, $sink2, to it). The problem is that the $sink2-ie is somehow corrupted to such an extent that trying to access anything on it hangs ie badly. There is a 2nd less severe but still significant problem: If the bug causing 2 lines just above the print \n; in BeforeNavigate2 are commented out, then the PHP code will terminate if either instance of IE is closed. However, there is also an error genereated at the same time (the specific error varies, but I suspect that it has to do with cleanup of the COM objects). Reproduce code: --- ?php // set_variant bug testing $aES = array(); // global array of IE event sinks $newIEpage = body . onload='document.links[0].click()' . a target=_blank . href='http://google.com'Goog/a/body; $ie = new COM(InternetExplorer.Application); sink_ie($ie); $ie-visible = true; $ie-Navigate2(about:blank); while ($ie-ReadyState4) com_message_pump(200); $ie-Navigate2(javascript:\$newIEpage\); $ie-document-title = variant_set Launcher; $keepLooping = true; while ($keepLooping) com_message_pump(200); print Exiting; class mysink { public $ie = null; // reqd for evt sink to function function __construct($ie) { $this-ie = $ie; } public function BeforeNavigate2 ( $ie, $url, $flags, $targetFrameName, $postData, $headers, $cancel) { print __FUNCTION__ . : . typename($ie) . , ; print $ie-hwnd . , rs: . $ie-ReadyState; print ; . $url . \n; global $aES; print Sink count: . sizeof($aES); print , this-ie: ; print typename($this-ie) . , ; // produces bug print $this-ie-hwnd; // produces bug print \n; } public function NewWindow2 ($newIe, $cancel) { $ie = new COM(InternetExplorer.Application); print NewWindow2: ; variant_set($newIe, $ie); $sink2 = sink_ie($ie); print $sink2-ie-hwnd . \n; } public function DownloadComplete() { print __FUNCTION__ . \n; } public function DocumentComplete($dom, $url) { print __FUNCTION__ . : $url\n; } public function onQuit() { print Quitting\n; $GLOBALS['keepLooping'] = false; } } function typename($objCOM) { // similar to typename in vbscript if (empty($objCOM)) return no COM object; if (gettype($objCOM)!=object) return not a COM object; ob_start(); com_print_typeinfo($objCOM); $typeInfo = ob_get_contents(); ob_end_clean(); $pattern = /^\\s*class (.*) \\{/; if (!($matchCnt = preg_match($pattern, $typeInfo, $aMatch))) return Not found; return COM: . $aMatch[1]; } function sink_ie($ie) { // sink $ie, and add to global array of sinks global $aES; com_event_sink ($ie, $aES[] = $sink = new mysink($ie), DWebBrowserEvents2); return $sink; } ? Expected result: This is PHP CLI code. When run from the cmd prompt, I expect two instances of IE to come up (they do), and for the cmd prompt to display the navigation progress. Now I could see that $sink2-ie becomes obsolete somehow (even though its hwnd is the same as the hwnd that comes into BeforeNavigate2), but what seems really wrong is to get a hang upon trying to do anything with that variable in BeforeNavigate2 (either $this-ie or $aES[sizeof($aES)-1]-ie) Actual result: -- If the included script is run as is, then typename($this-ie) causes a hang. If it is commented out, $this-ie-hwnd causes a hang. If both of these statements (the two lines before the last print statement in BeforeNavigate2) are commented out, then both IE pages will load OK (ie. the main bug goes away), and there will only be issues when the php code shuts down on account of one of the two IE's being closed. A note about the code: While it may appear somewhat convoluted, the point of the original code was to track navigation progress within ie, and this works fine. However, when (simulated) clicking on a link causes the browser to open a new window, then navigation tracking must continue with a new ie, and the way to get ahold of that ie is with the NewWindow2 or NewWindow3 event, and I used the former. Two things need to happen in NewWindow2. The first is that the first argument to the event handler needs to be set to an uninitiated, fresh IE. The second is that this new IE needs to be sinked. Because we're in an event handler, globals are not so good, but since event sinks require a reference to their COM object, the sink gets an IE variable. The variable is not superfluous: if you make
#43839 [NEW]: Cast problem with the equal operator (==)
From: technique at ircf dot fr Operating system: Linux Ubuntu PHP version: 5.2CVS-2008-01-14 (snap) PHP Bug Type: Scripting Engine problem Bug description: Cast problem with the equal operator (==) Description: I have noticed that the equal operator will systematically try to cast expressions as integers, even when it is useless. This may cause problems like this (see the code below). Wouldn't be better to cast only one operand ONLY if the two operands are not of the same type ? For example : 1 == 1 , would cast the right operand (1) as a string and then compare it with the first 123 == 456, would not cast any operand because they already have the same type I know that this issue can be solved using the identity operator (===) but I find weird that 001 == 0001 returns true, or am I missing something ? Reproduce code: --- ?php if (0001 == 01){ echo Impossible !!!; } ? Expected result: Nothing Actual result: -- Impossible !!! -- Edit bug report at http://bugs.php.net/?id=43839edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43839r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43839r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43839r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43839r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43839r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43839r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43839r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43839r=needscript Try newer version:http://bugs.php.net/fix.php?id=43839r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43839r=support Expected behavior:http://bugs.php.net/fix.php?id=43839r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43839r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43839r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43839r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43839r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43839r=dst IIS Stability:http://bugs.php.net/fix.php?id=43839r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43839r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43839r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43839r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43839r=mysqlcfg
#43835 [Opn-Bgs]: misstyped fields num in actual results
ID: 43835 Updated by: [EMAIL PROTECTED] Reported By: alexander dot varchenko at gmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: FreeBSD,Linux,Windows PHP Version: 5.2.5 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. An invalid CSV format is not going to be supported. The enclosure character needs to be escaped to ensure proper data parsing. Previous Comments: [2008-01-14 00:20:23] alexander dot varchenko at gmail dot com ! In Actual Result - 3 fields in line x [2008-01-14 00:17:07] alexander dot varchenko at gmail dot com Description: Not every programs escapes enclosure characters, so it's should be good to check enclosures by delimiters chars start =delimiter+enclosure fin = enclosure+delimiter TEST data: test.csv [TSV] 1[tab]NOAA Official Emergency[tab]01/09/2008 2[tab]Tories reject green panel's advice[tab]01/09/2008 Reproduce code: --- ? $handle = fopen('test.csv','rb'); $row = 1; while (($data = fgetcsv($handle, 1000, \t,'')) !== FALSE) { $num = count($data); echo $num fields in line $row\n; $row++; for ($c=0; $c $num; $c++) { echo [$c]:.$data[$c].\n; } } fclose($handle); ? Expected result: 3 fields in line 1 [0]:1 [1]:NOAA Official Emergency [2]:01/09/2008 3 fields in line 2 [0]:2 [1]:Tories reject green panel's advice [2]:01/09/2008 Actual result: -- 4 fields in line 1 [0]:1 [1]:NOAA Official Emergency [2]:01/09/2008 4 fields in line 2 [0]:2 [1]:Tories reject green panel's advice [2]:01/09/2008 -- Edit this bug report at http://bugs.php.net/?id=43835edit=1
#43839 [Opn-Bgs]: Cast problem with the equal operator (==)
ID: 43839 Updated by: [EMAIL PROTECTED] Reported By: technique at ircf dot fr -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux Ubuntu PHP Version: 5.2CVS-2008-01-14 (snap) 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 Numeric strings are understood as numeric values. This is not exactly an int cast. i.e. 01a == 001a is not true, as the operands are not numeric. however (int)01a == (int)001a == 1 Previous Comments: [2008-01-14 13:33:25] technique at ircf dot fr Description: I have noticed that the equal operator will systematically try to cast expressions as integers, even when it is useless. This may cause problems like this (see the code below). Wouldn't be better to cast only one operand ONLY if the two operands are not of the same type ? For example : 1 == 1 , would cast the right operand (1) as a string and then compare it with the first 123 == 456, would not cast any operand because they already have the same type I know that this issue can be solved using the identity operator (===) but I find weird that 001 == 0001 returns true, or am I missing something ? Reproduce code: --- ?php if (0001 == 01){ echo Impossible !!!; } ? Expected result: Nothing Actual result: -- Impossible !!! -- Edit this bug report at http://bugs.php.net/?id=43839edit=1
#34667 [Com]: Notice: Unknown: Unable to find the wrapper compress.bzip2.....
ID: 34667 Comment by: lord dot arrogant at gmail dot com Reported By: webmaster at 24-99-92-156 dot no-ip dot com Status: No Feedback Bug Type: Bzip2 Related Operating System: Windows Server 2003 Ent. SP1 PHP Version: 5.0.5 New Comment: I am running 5.2.5 on WinXP Pro with Apache 2.2.6 and the error is always there when I first open my browser and load a page. If I reload the page immediately the error disappears. I have loaded the bz2. Previous Comments: [2008-01-03 18:04:38] jpenn at rcn dot com I am running PHP 5.2.5 Windows 2000 server and IIS 5. I get the same error when error_reporting = E_ALL is set in the php.ini file. I have it set to E_STRICT and I am no longer recieving this error. JP [2008-01-03 17:04:39] computerlov at yahoo dot com Here's how to reproduce the bug: you need to have your php.ini file configured to display errors and show errors E_ALL | E_STRICT I had E_ALL and it didn't show up. Once adding E_STRICT, it started popping as reported before. Maybe the new snapshot didn't have E_STRICT in the ini file. Php version i'm using: 5.2.5 (Downloaded it in December 2007) I'm using windows binaries. Cheers. [2007-11-12 13:41:39] abouzekry at gmail dot com The Problem also appears to exist in PHP 5.2.0, on WinXP Professional,...but the probability of it's appear is random!!! [2007-09-16 14:31:33] gfj at gfhdf dot hgi http://www.meta-fx.com [2006-11-10 19:28:07] saulovallory at yahoo dot com I was having the same problem. The last snapshot (link above) solved it. 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/34667 -- Edit this bug report at http://bugs.php.net/?id=34667edit=1
#43207 [Com]: .htaccess settings missing (sometimes)
ID: 43207 Comment by: dan at eskhosting dot com Reported By: phpmyforum at gmail dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 5.2.5RC2 New Comment: register_globals are switching On/Off randomise! Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no difference. Only global setting in php.ini are effective. Other variables works good. System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6) PHP: 5.2.5 './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--prefix=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc' '--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2' Apache: 1.3.37 Previous Comments: [2007-11-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-11-11 18:49:12] [EMAIL PROTECTED] Try change the php_flag to php_value and use 0 or 1 as value. [2007-11-06 18:25:23] phpmyforum at gmail dot com Description: Since I upgraded from php4 to PHP 5.2.5RC2 .htaccess php_* options getting ignored. This happens for most, but not all requests. The default (php.ini) option for register_globals is off. My .htaccess file looks like this: php_flag register_globals on Now I downgraded to PHP 5.2.4 and it's working again. Hint: this bug looks very similar to #28522. PS: this may happen for other options './configure' '--prefix=/bbo/php' '--with-apxs2=/bbo/apachessl/bin/apxs' '--with-config-file-path=/bbo/etc/httpd' '--with-openssl=/bbo/usr' '--with-zlib' '--with-zlib-dir=/bbo/usr' '--with-bz2=/bbo/usr' '--enable-ftp' '--enable-exif' '--with-gd=/bbo/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=/bbo/usr' '--with-png-dir=/bbo/usr' '--with-freetype-dir=/bbo/usr' '--with-mysql=/bbo/usr' '--with-mysqli=/bbo/usr/bin/mysql_config' '--with-pdo-mysql=/bbo/usr' '--with-iconv' '--with-iconv-dir=/bbo/usr' '--with-curl=/bbo/usr' '--with-curlwrappers' '--enable-soap' '--enable-sockets' '--enable-mbstring=all' '--enable-mbregex' '--with-xsl=/bbo/usr' '--with-libxml-dir=/bbo/usr' '--with-pspell=/bbo/usr' '--with-ldap=/bbo/usr' '--with-tidy=/bbo/usr' '--with-gettext=/bbo/usr' '--with-mcrypt=/bbo/usr' '--with-pcre-regex=/bbo/usr' '--enable-sigchild' '--enable-sysvshm' '--enable-sysvsem' '--enable-zip' '--disable-short-tags' '--with-pear=/bbo/php_includes' '--with-imap=/download/webserver/files/imap/' '--with-imap-ssl' '--without-kerberos' -- Edit this bug report at http://bugs.php.net/?id=43207edit=1
#43207 [Com]: .htaccess settings missing (sometimes)
ID: 43207 Comment by: dan at eskhosting dot com Reported By: phpmyforum at gmail dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 5.2.5RC2 New Comment: php_value/php_flag - no different too. Previous Comments: [2008-01-14 16:05:14] dan at eskhosting dot com register_globals are switching On/Off randomise! Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no difference. Only global setting in php.ini are effective. Other variables works good. System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6) PHP: 5.2.5 './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--prefix=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc' '--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2' Apache: 1.3.37 [2007-11-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-11-11 18:49:12] [EMAIL PROTECTED] Try change the php_flag to php_value and use 0 or 1 as value. [2007-11-06 18:25:23] phpmyforum at gmail dot com Description: Since I upgraded from php4 to PHP 5.2.5RC2 .htaccess php_* options getting ignored. This happens for most, but not all requests. The default (php.ini) option for register_globals is off. My .htaccess file looks like this: php_flag register_globals on Now I downgraded to PHP 5.2.4 and it's working again. Hint: this bug looks very similar to #28522. PS: this may happen for other options './configure' '--prefix=/bbo/php' '--with-apxs2=/bbo/apachessl/bin/apxs' '--with-config-file-path=/bbo/etc/httpd' '--with-openssl=/bbo/usr' '--with-zlib' '--with-zlib-dir=/bbo/usr' '--with-bz2=/bbo/usr' '--enable-ftp' '--enable-exif' '--with-gd=/bbo/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=/bbo/usr' '--with-png-dir=/bbo/usr' '--with-freetype-dir=/bbo/usr' '--with-mysql=/bbo/usr' '--with-mysqli=/bbo/usr/bin/mysql_config' '--with-pdo-mysql=/bbo/usr' '--with-iconv' '--with-iconv-dir=/bbo/usr' '--with-curl=/bbo/usr' '--with-curlwrappers' '--enable-soap' '--enable-sockets' '--enable-mbstring=all' '--enable-mbregex' '--with-xsl=/bbo/usr' '--with-libxml-dir=/bbo/usr' '--with-pspell=/bbo/usr' '--with-ldap=/bbo/usr' '--with-tidy=/bbo/usr' '--with-gettext=/bbo/usr' '--with-mcrypt=/bbo/usr' '--with-pcre-regex=/bbo/usr' '--enable-sigchild' '--enable-sysvshm' '--enable-sysvsem' '--enable-zip' '--disable-short-tags' '--with-pear=/bbo/php_includes' '--with-imap=/download/webserver/files/imap/' '--with-imap-ssl' '--without-kerberos' -- Edit this bug report at http://bugs.php.net/?id=43207edit=1
#43841 [NEW]: mb_strrpos offset is byte count for negative values
From: josmessa at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2CVS-2008-01-14 (snap) PHP Bug Type: mbstring related Bug description: mb_strrpos offset is byte count for negative values Description: The offset argument appears to do a byte count for negative values of offset. In the example below, $string_ascii is 21 characters long and $string_mb is 21 characters (53 bytes) long. In both cases the needle appears twice, first at position 9 and secondly at position 20. When the offset is -24, beyond the character length of the string, it finds $needle at position 9, when $needle would be expected to be found when offest is -12 (i.e. behave the same as the ASCII example). It's also worth noting that strrpos returns a notice when the offset is outside the boundary of the string whereas mb_strrpos does not. This may be linked to this bug: http://bugs.php.net/43840. Reproduce code: --- ?php $offsets = array(-25, -24, -13, -12); $string_mb = base64_decode('5pel5pys6Kqe44OG44Kt44K544OI44Gn44GZ44CCMDEyMzTvvJXvvJbvvJfvvJjvvJnjgII='); $needle = base64_decode('44CC'); foreach ($offsets as $i) { echo \n-- Offset is $i --\n; echo Multibyte String:\t; var_dump( mb_strrpos($string_mb, $needle, $i, 'UTF-8') ); echo ASCII String:\n; echo mb_strrpos:\t\t; var_dump(mb_strrpos('This is na English ta', 'a', $i)); echo strrpos:\t\t; var_dump(strrpos('This is na English ta', 'a', $i)); } ? Expected result: -- Offset is -25 -- Multibyte String: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 9 bool(false) ASCII String: mb_strrpos: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -24 -- Multibyte String: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 9 bool(false) ASCII String: mb_strrpos: Notice: mb_strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -13 -- Multibyte String: bool(false) ASCII String: mb_strrpos: bool(false) strrpos:bool(false) -- Offset is -12 -- Multibyte String: int(9) ASCII String: mb_strrpos: int(9) strrpos:int(9) Actual result: -- -- Offset is -25 -- Multibyte String: bool(false) ASCII String: mb_strrpos: bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -24 -- Multibyte String: int(9) ASCII String: mb_strrpos: bool(false) strrpos: Notice: strrpos(): Offset is greater than the length of haystack string in ...\mb_strrpos.php on line 14 bool(false) -- Offset is -13 -- Multibyte String: int(9) ASCII String: mb_strrpos: bool(false) strrpos:bool(false) -- Offset is -12 -- Multibyte String: int(9) ASCII String: mb_strrpos: int(9) strrpos:int(9) -- Edit bug report at http://bugs.php.net/?id=43841edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43841r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43841r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43841r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43841r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43841r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43841r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43841r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43841r=needscript Try newer version:http://bugs.php.net/fix.php?id=43841r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43841r=support Expected behavior:http://bugs.php.net/fix.php?id=43841r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43841r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43841r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43841r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43841r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43841r=dst IIS Stability:http://bugs.php.net/fix.php?id=43841r=isapi Install GNU Sed:
#43840 [NEW]: mb_strpos bounds check is byte count rather than a character count
From: josmessa at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2CVS-2008-01-14 (snap) PHP Bug Type: mbstring related Bug description: mb_strpos bounds check is byte count rather than a character count Description: The bounds check for the offest argument in mb_strpos appears to be a byte count rather than a character count. In the example below, $string_ascii is 21 characters long and $string_mb is 21 characters (53 bytes) long. In both cases the needle appears twice, first at position 9 and secondly at position 20. With the multibyte string example, when the offset is past the character count of the string it would be expected to return a warning but instead a warning is returned when offest is past the byte count. Reproduce code: --- ?php $offsets = array(20, 21, 22, 53, 54); $string_mb = base64_decode('5pel5pys6Kqe44OG44Kt44K544OI44Gn44GZ44CCMDEyMzTvvJXvvJbvvJfvvJjvvJnjgII='); $needle = base64_decode('44CC'); foreach($offsets as $i) { echo \n-- Offset is $i --\n; echo --Multibyte String:--\n; var_dump( mb_strpos($string_mb, $needle, $i, 'UTF-8') ); echo--ASCII String:--\n; var_dump(mb_strpos('This is na English ta', 'a', $i)); } ? Expected result: -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) Actual result: -- -- Offset is 20 -- --Multibyte String:-- int(20) --ASCII String:-- int(20) -- Offset is 21 -- --Multibyte String:-- bool(false) --ASCII String:-- bool(false) -- Offset is 22 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 53 -- --Multibyte String:-- bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Offset is 54 -- --Multibyte String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 9 bool(false) --ASCII String:-- Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php on line 11 bool(false) -- Edit bug report at http://bugs.php.net/?id=43840edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43840r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43840r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43840r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43840r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43840r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43840r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43840r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43840r=needscript Try newer version:http://bugs.php.net/fix.php?id=43840r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43840r=support Expected behavior:http://bugs.php.net/fix.php?id=43840r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43840r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43840r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43840r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43840r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43840r=dst IIS Stability:http://bugs.php.net/fix.php?id=43840r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43840r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43840r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43840r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43840r=mysqlcfg
#43842 [Opn]: gerister_globals randomise switching value On/Off
ID: 43842 User updated by: dan at eskhosting dot com Reported By: dan at eskhosting dot com Status: Open Bug Type: *Configuration Issues Operating System: Linux Red Hat ES 4 PHP Version: 5.2.5 New Comment: Apache 1.3.37 PHP as module. 5.2.3 worked without this problem.. Previous Comments: [2008-01-14 16:54:29] dan at eskhosting dot com Description: Set up value for gerister_globals take a random effect. Reproduce code: --- php.ini: register_globals = Off .htaccess: php_flag register_globals On Expected result: register_globals On Actual result: -- ? phpinfo(); ? reports: register_globals On/Off - randomise! -- Edit this bug report at http://bugs.php.net/?id=43842edit=1
#36923 [Com]: PDO::query fails when query contains special charactes
ID: 36923 Comment by: stoto98 at yahoo dot fr Reported By: farin at refresh dot cz Status: No Feedback Bug Type: PDO related Operating System: Gentoo PHP Version: 5.1.2 New Comment: Same error for me with PHP 5.2.0-8+etch9 (debian) with client library version 5.0.32 (MySQL) Previous Comments: [2007-10-04 11:24:17] gizmo dot rafal at poczta dot fm I have same issue on my PHP Version 5.2.3-0.dotdeb.1 with PDO Driver for MySQL, client library version 5.0.41. [2007-08-09 22:36:01] apike at sfu dot ca This is still happening for me with PHP 5.2.0. [2006-04-07 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-03-30 13:29:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-03-30 13:27:39] farin at refresh dot cz Description: When $query parameter for PDO::query contains ' :A and ? (as part of data) query fails with error Invalid parameter number: mixed named and positional parameters. This behavior is appear with PDO mysql driver. In PHP 5.1.1 is not this bug present. Reproduce code: --- $pdo-query(insert into foo (bar) values ('\\ ? :A')); Expected result: SQL syntax is Ok so query should be proccessed without error. Actual result: -- Warning: PDO::query() [function.query]: SQLSTATE[HY093]: Invalid parameter number: mixed named and positional parameters in ... And query fails. -- Edit this bug report at http://bugs.php.net/?id=36923edit=1
#43844 [NEW]: muliple odbc_execute() on prepared select statement with bind parms (IBM ODBC)
From: kennya at carlislefsp dot com Operating system: Debian Linux 4.0 PHP version: 5.2.5 PHP Bug Type: ODBC related Bug description: muliple odbc_execute() on prepared select statement with bind parms (IBM ODBC) Description: OS: Debian Linux 4.0 PHP: 5.2.0-8+etch9 and 5.2.25 unixODBC: 2.2.11-13 ODBC Driver: IBM iSeries Access for Linux V5R4, Version 1.4 Second execution of a prepared select statement with bind parameters fails. Through trial and error, I found that it'll actually work if I: #1) don't define any variables between odbc_execute() #2) cycle through all of the results OR comment out the SQLFreeStmt(.. SQL_RESET_PARAMS) in ext/odbc/php_odbc.c line #1102, ie: --cut-- if (result-numparams 0) { /* SQLFreeStmt(result-stmt, SQL_RESET_PARAMS); */ for(i = 0; i result-numparams; i++) { if (params[i].fp != -1) close(params[i].fp); } efree(params); } --cut-- I'm not a C guy. I figure the above is present for a reason, I've just noticed that removing it fixes this problem for this version of of the IBM ODBC/DB2 driver. Reproduce code: --- $conn = odbc_connect('host','user','pass'); $stmt='select cn from ldapusr where cn like ?'; $res =odbc_prepare($conn, $stmt); if (! odbc_execute($res, array('%ken%'))) { trigger_error(odbc_error($conn) . ': ' . odbc_errormsg($conn), E_USER_ERROR); } if (odbc_fetch_row($res)) { print odbc_result($res, 1) . \n; } //$anything='asdf'; // add this and it stops working while (odbc_fetch_row($res)) {} // remove this and it stops working print 'Second:\n'; if (! odbc_execute($res, array('%steve%'))) { trigger_error(odbc_error($conn) . ': ' . odbc_errormsg($conn), E_USER_ERROR); } if (odbc_fetch_row($res)) { print odbc_result($res, 1) . \n; } Expected result: records Actual result: -- 07001: [unixODBC][IBM][iSeries Access ODBC Driver]Wrong number of parameters. -- Edit bug report at http://bugs.php.net/?id=43844edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43844r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43844r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43844r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43844r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43844r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43844r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43844r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43844r=needscript Try newer version:http://bugs.php.net/fix.php?id=43844r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43844r=support Expected behavior:http://bugs.php.net/fix.php?id=43844r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43844r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43844r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43844r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43844r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43844r=dst IIS Stability:http://bugs.php.net/fix.php?id=43844r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43844r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43844r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43844r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43844r=mysqlcfg
#43845 [NEW]: Function can no longer be called both statically and as instance method
From: ms419 at freezone dot co dot uk Operating system: PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: Function can no longer be called both statically and as instance method Description: I understand that, unlike some other languages, PHP does not support overloading: I can't implement two functions with the same name but different signatures. However I can simulate overloading using func_get_args() and testing with which arguments the function was called. Now what I want is a function which can be called either as an instance method with no arguments, or statically with one argument: an instance of the class. I test whether the function was called statically or not using isset($this) However in PHP5, this produces an error: Non-static method BaseTaxonomy::getTerms() should not be called statically in... Like it is possible to simulate overloading in PHP without generating errors, I wish it were possible to define a function which can be called either statically or as an instance method, without generating errors. Much thanks, Jack Reproduce code: --- Toy example: class BaseTaxonomy { protected $terms = null; public function getTerms() { if (!isset($this)) { $args = func_get_args(); return $args[0]-terms; } return $this-terms; } } Actual result: -- Non-static method BaseTaxonomy::getTerms() should not be called statically in... -- Edit bug report at http://bugs.php.net/?id=43845edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43845r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43845r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43845r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43845r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43845r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43845r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43845r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43845r=needscript Try newer version:http://bugs.php.net/fix.php?id=43845r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43845r=support Expected behavior:http://bugs.php.net/fix.php?id=43845r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43845r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43845r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43845r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43845r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43845r=dst IIS Stability:http://bugs.php.net/fix.php?id=43845r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43845r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43845r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43845r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43845r=mysqlcfg
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.4 Assigned To: iliaa New Comment: Any idea when this issue might get fixed? This is a big deal to us, since this bug prevents us from swapping out filesystem-based storage with a db-storage engine. Previous Comments: [2007-10-01 20:04:40] hans at velum dot net Updating version to reflect that problem is still present in 5.2.4 [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! [2007-09-06 13:36:53] hans at velum dot net Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#43846 [NEW]: Switch statement broken when using 'null' value
From: php_bug at jldupont dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: Switch statement broken when using 'null' value Description: The 'switch' statement does not correctly handle the case where the switch value === null. Reproduce code: --- The following code should show null, true, false: function testSwitch( $v ) { return $v; } function showResult( $r ) { $v = testSwitch( $r ); switch ($v) { case false: echo false; break; case null: echo null; break; case true: echo true; break; } echo \nbr/; } showResult( null ); showResult( true ); showResult( false ); Expected result: null true false Actual result: -- false true false -- Edit bug report at http://bugs.php.net/?id=43846edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43846r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43846r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43846r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43846r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43846r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43846r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43846r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43846r=needscript Try newer version:http://bugs.php.net/fix.php?id=43846r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43846r=support Expected behavior:http://bugs.php.net/fix.php?id=43846r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43846r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43846r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43846r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43846r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43846r=dst IIS Stability:http://bugs.php.net/fix.php?id=43846r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43846r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43846r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43846r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43846r=mysqlcfg
#43846 [Opn-Bgs]: Switch statement broken when using 'null' value
ID: 43846 Updated by: [EMAIL PROTECTED] Reported By: php_bug at jldupont dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.2.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2008-01-14 21:21:36] php_bug at jldupont dot com Description: The 'switch' statement does not correctly handle the case where the switch value === null. Reproduce code: --- The following code should show null, true, false: function testSwitch( $v ) { return $v; } function showResult( $r ) { $v = testSwitch( $r ); switch ($v) { case false: echo false; break; case null: echo null; break; case true: echo true; break; } echo \nbr/; } showResult( null ); showResult( true ); showResult( false ); Expected result: null true false Actual result: -- false true false -- Edit this bug report at http://bugs.php.net/?id=43846edit=1
#41608 [Opn-Fbk]: Apache crash because of script
ID: 41608 Updated by: [EMAIL PROTECTED] Reported By: aigors at inbox dot lv -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 Assigned To: tony2001 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2007-12-18 09:47:50] aigors at inbox dot lv Bug still exists in PHP 5.2.5. [2007-06-06 08:35:53] [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. [2007-06-06 07:44:20] aigors at inbox dot lv Description: Apache crash because of script containing set_error_handler function. Reproduce code: --- /***Main php file***/ ?php function MyErrorHandler($errno, $errstr, $errfile, $errline){ include_once('empty.php'); } set_error_handler(MyErrorHandler); include_once('blah.php'); echo('I am done'); ? /***blah.php file***/ ?php class Blah { function foo($value, $classname) { switch(strtolower($value['key'])) { default: $x = new $classname; } } } ? /***empty.php file - no content***/ Expected result: Should output I am done Actual result: -- Apache crash -- Edit this bug report at http://bugs.php.net/?id=41608edit=1
#42443 [Com]: PDO SQLite3 lacks integer type support
ID: 42443 Comment by: lapo at lapo dot it Reported By: [EMAIL PROTECTED] Status: Open Bug Type: SQLite related Operating System: * PHP Version: 6CVS-2007-08-27 (CVS) New Comment: Even worse than the integer case (which leads to inefficience) is the case of BLOBs, which leads to corruption of data: text values can't contain \0, while blob data can. E.g. from command line sqlite3: sqlite SELECT LENGTH(X'1200'); 4 sqlite SELECT LENGTH(CAST(X'1200' AS text)); 1 Because case PDO_PARAM_LOB falls through to case PDO_PARAM_STR, which uses sqlite3_bind_text... using PDO is impossible to store BLOB data in Sqlite3. Previous Comments: [2007-08-27 10:42:16] [EMAIL PROTECTED] Description: PDO SQLite3 calls sqlite3_bind_text() for all non-blob and non-null parameter types regardless of whether integer data is provided. Integer data can be bound with sqlite3_bind_int(), which saves memory space and improves efficiency, as well as storing the intended type in a database which uses SQLite3's value typing. Patch is at: http://news.php.net/php.internals/31935 Reproduce code: --- Difficult to show reproduction. Expected result: Difficult to show reproduction. Actual result: -- Difficult to show reproduction. -- Edit this bug report at http://bugs.php.net/?id=42443edit=1
#42850 [Opn-Csd]: array_walk_recursive() leaves references
ID: 42850 Updated by: [EMAIL PROTECTED] Reported By: ltaupiac at lfdj dot com -Status: Open +Status: Closed Bug Type: Arrays related Operating System: windows/solaris PHP Version: 5.3.0-dev 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: [2007-11-26 08:00:18] ltaupiac at lfdj dot com I have tested on window with apache 2.2.6 the snap.zip you given. The bug is still there. A for reference is still leaved after call array_walk_recursive on val2 and original array can't be duplicate anymore after. Reproduce code: -- echo PHP_VERSION; $data = array ('key1' = 'val1', array('key2' = 'val2')); echo 'pre'; function foo2($item, $key) {}; // dumb callback function var_dump($data); array_walk_recursive($data, 'foo2'); $data2 = $data; // Duplicate array $data2[0] = 'altered'; // Alter copy var_dump($data); var_dump($data2); Expected result: 5.3.0-dev array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } array(2) { [key1]= string(4) val1 [0]= string(7) val2 } array(2) { [key1]= string(4) val1 [0]= string(7) altered } Actual result: -- 5.3.0-dev array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } array(2) { [key1]= string(4) val1 [0]= string(7) altered } array(2) { [key1]= string(4) val1 [0]= string(7) altered } [2007-11-25 17:35:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2007-10-04 08:10:34] ltaupiac at lfdj dot com Description: I have to reopen this bug http://bugs.php.net/bug.php?id=42655 because it was incorrectly closed and tony2001 doesn't seem to receive email. Here Copy/paste email i send him. This is not the same bug. In #34982, an array is modified outside the function func() that call array_walk_recursive. This bug doesn't exist anymore in 5.2.4 The bug i report is when calling array_walk_recursive on an array (callback function doesn't even have reference for array input and does nothing). Original array shouldn't be modified, but if you var_dump it, you can see reference on subarray [0]= array(1) instead of [0]= array(1) The array shouldn't have been modified but array_walk_recursive leaves references. This can cause trouble, eg you cant duplicate the original array anymore. Look at following example $data = array ('key1' = 'val1', array('key2' = 'val2')); function foo($item, $key) {}; // dumb callback function var_dump($data); array_walk_recursive($data, 'foo'); $data2 = $data; // Duplicate array $data2[0] = 'altered'; // Alter copy var_dump($data); var_dump($data2); array(2) { [key1]= string(4) val1 [0]= string(5) bingo } array(2) { [key1]= string(4) val1 [0]= string(5) bingo } both $data and $data2 are altered; Reproduce code: --- $data = array ('key1' = 'val1', array('key2' = 'val2')); function dumb($i, $k){} var_dump($data); array_walk_recursive($data,'foo'); // Double check the [0]=array(1) in actual result var_dump($data); Expected result: Expected result: array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } Actual result: -- Actual result: -- array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } array(2) { [key1]= string(4) val1 [0]= array(1) { [key2]= string(4) val2 } } -- Edit this bug report at http://bugs.php.net/?id=42850edit=1
#43847 [NEW]: Bug #34396 is not fixed - unset() un-declares a property
From: timshaw at mail dot usa dot com Operating system: Win32 PHP version: 5.2.5 PHP Bug Type: Class/Object related Bug description: Bug #34396 is not fixed - unset() un-declares a property Description: Shouldn't unset of a declared property still leave the property as a declared property, so that the set overload will not later be used on it? It is cool to unset things once their value becomes invalid to catch errors using the invalid value. However, I could understand that this overload problem is actually an undocumented feature if the person who implemented overloads decided that everybody should be able to overload everything, even declared properties, so this was put in to allow that Too bad that doesn't accomodate those of us who don't want to use overloads for everything, just some things. Reproduce code: --- ?php class c { public $x ; public function __set($nm, $val) { echo overloaded __set($nm, $val) ;\n ; } public function __isset($nm) { echo overloaded __isset($nm) ;\n ; } public function __unset($nm) { echo overloaded __unset($nm) ;\n ; } } $c = new c ; echo Does not overload, just as expected and documented, because \$x is declared property\n ; echo \$c-x = , $c-x = 5, \n ; echo Does not overload, just as expected, because \$x is declared property\n ; echo isset(\$c-x) = , isset($c-x)? 'True': 'False', \n ; echo Does not use overload __unset, just as expected, because \$x is declared property\n ; echo unset(\$c-x)\n ; unset($c-x) ; echo Here's the problem- \$x is declared public property, but now it's using overloaded set!\n ; echo \$c-x = 5 ... ; $c-x = 5 ; ? Expected result: The overloaded ... should not appear because only the declared property $x is used. Actual result: -- This does not call overload, just as expected and documented, because $x is declared property $c-x = 5 This does not call overload, just as expected, because $x is declared property isset($c-x) = True This does not go though __unset, just as expected, because $x is declared property unset($c-x) Here's the problem- $x is declared public property, but now it's using overloaded set! $c-x = 5 ... overloaded __set(x, 5) ; -- Edit bug report at http://bugs.php.net/?id=43847edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43847r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43847r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43847r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43847r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43847r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43847r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43847r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43847r=needscript Try newer version:http://bugs.php.net/fix.php?id=43847r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43847r=support Expected behavior:http://bugs.php.net/fix.php?id=43847r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43847r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43847r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43847r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43847r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43847r=dst IIS Stability:http://bugs.php.net/fix.php?id=43847r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43847r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43847r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43847r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43847r=mysqlcfg
#43497 [Asn]: OCI8 XML/getClobVal leaks UGA memory
ID: 43497 Updated by: [EMAIL PROTECTED] Reported By: ghosh at q-one dot com Status: Assigned Bug Type: OCI8 related Operating System: Linux 2.6.22-14-server PHP Version: 5.2.5 Assigned To: sixd New Comment: An enhanced patch was sent to the bug filer and Tony on 8th Jan. I'm still waiting for feedback . . . Previous Comments: [2008-01-06 23:17:34] ghosh at q-one dot com Temporary LOBs are created in UGA memory. This is per-session, so the leak appears on a per-session basis. Nevertheless this is a problem, because PHP scripts dont necessarily have to run for a few seconds. PHP is a full-featured scripting language and can also be used from the command-line or to implement longer-running import-scripts. Even if not, the limit is quickly reached, when reading many rows like in my example. [2008-01-06 20:42:52] [EMAIL PROTECTED] What I don't understand: I thought OCI_RETURN_LOBS is just a short- cut for those who don't want to write: That's what I don't understand either: does the leak appear only on per-session basis or Oracle doesn't free those LOBs at all? If the leak is only per-session, then users are not supposed even to notice it, since PHP requests are not supposed to take more than several seconds. [2007-12-29 22:37:21] ghosh at q-one dot com Really great! Thanks a lot!! This patch works. What I don't understand: I thought OCI_RETURN_LOBS is just a short-cut for those who don't want to write: $s=$result[0]-load(); $result[0]-free(); $result[0]=$s; If you use OCI_RETURN_LOBS you dont want to care about lobs but get the result as a string and forget about lobs altogether. So IMHO this should work as well. My specific problem is solved though. [2007-12-27 21:44:07] [EMAIL PROTECTED] This is really an issue with temporary LOBS since getClobVal() returns a temporary LOB. There are two parts to the fix: changing the script and patching the OCI8 extension. Also don't forget to apply the patch for http://bugs.php.net/bug.php?id=42496 Please test this suggestion and report any issues. Thanks to Krishna Shankar for the solution. 1. Change the test to get the results as LOBs, not as strings. This allows the script to free temporary LOBs. In the supplied testcase change: $query = select extract(xml, '/').getclobval() from ugatest; $stmt = oci_parse($conn, $query); if (oci_execute($stmt)) while ($result = oci_fetch_array($stmt, OCI_NUM+OCI_RETURN_LOBS)) ; to: $query = select extract(xml, '/').getclobval() from ugatest; $stmt = oci_parse($conn, $query); if (oci_execute($stmt)) while ($result = oci_fetch_array($stmt, OCI_NUM)) { // echo $result[0]-load(), \n; // do something with the XML $result[0]-free(); // free the temporary LOB } The connection must be open when LOB-free() is called, as the underlying OCILobFreeTemporary() call does a roundtrip to the database. 2. Patch oci8_lob.c. The change copies some LOB freeing code from php_oci_lob_close() into php_oci_lob_free(): --- oci8_lob.c.orig2007-07-31 12:21:08.0 -0700 +++ oci8_lob.c2007-12-27 12:33:19.0 -0800 @@ -647,6 +647,9 @@ Close LOB descriptor and free associated resources */ void php_oci_lob_free (php_oci_descriptor *descriptor TSRMLS_DC) { +#ifdef HAVE_OCI8_TEMP_LOB +int is_temporary; +#endif if (!descriptor || !descriptor-connection) { return; @@ -662,6 +665,40 @@ php_oci_lob_flush(descriptor, OCI_LOB_BUFFER_FREE TSRMLS_CC); } +#ifdef HAVE_OCI8_TEMP_LOB +if (descriptor-type == OCI_DTYPE_LOB) { +PHP_OCI_CALL_RETURN(descriptor-connection-errcode, +OCILobIsTemporary, +( +descriptor-connection-env, +descriptor-connection-err, +descriptor-descriptor, +is_temporary + ) +); +if (descriptor-connection-errcode != OCI_SUCCESS) { +php_oci_error(descriptor-connection-err, descriptor-connection-errcode TSRMLS_CC); +PHP_OCI_HANDLE_ERROR(descriptor-connection, descriptor-connection-errcode); +return 1; +} +if (is_temporary) { +PHP_OCI_CALL_RETURN(descriptor-connection-errcode, +OCILobFreeTemporary, +( +descriptor-connection-svc, +descriptor-connection-err, +descriptor-descriptor + ) +); +if (descriptor-connection-errcode != OCI_SUCCESS) { +
#43842 [NEW]: gerister_globals randomise switching value On/Off
From: dan at eskhosting dot com Operating system: Linux Red Hat ES 4 PHP version: 5.2.5 PHP Bug Type: *Configuration Issues Bug description: gerister_globals randomise switching value On/Off Description: Set up value for gerister_globals take a random effect. Reproduce code: --- php.ini: register_globals = Off .htaccess: php_flag register_globals On Expected result: register_globals On Actual result: -- ? phpinfo(); ? reports: register_globals On/Off - randomise! -- Edit bug report at http://bugs.php.net/?id=43842edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43842r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43842r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43842r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43842r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43842r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43842r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43842r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43842r=needscript Try newer version:http://bugs.php.net/fix.php?id=43842r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43842r=support Expected behavior:http://bugs.php.net/fix.php?id=43842r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43842r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43842r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43842r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43842r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43842r=dst IIS Stability:http://bugs.php.net/fix.php?id=43842r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43842r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43842r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43842r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43842r=mysqlcfg
#43848 [NEW]: Should be an option to disable echo when reading php://stdin
From: graced at wingsnw dot com Operating system: Irrelevant PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: Should be an option to disable echo when reading php://stdin Description: Short of using an experimental extension that's not likely to be available on a default install, there appears to be no way to disable/enable echoing of stdin content when reading it. A use case would be something like: ?php ob_implicit_flush(true); echo Please enter your password: ; // code to disable echo here $password = fgets(STDIN); // code to re-enable echo here. -- Edit bug report at http://bugs.php.net/?id=43848edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43848r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43848r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43848r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43848r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43848r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43848r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43848r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43848r=needscript Try newer version:http://bugs.php.net/fix.php?id=43848r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43848r=support Expected behavior:http://bugs.php.net/fix.php?id=43848r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43848r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43848r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43848r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43848r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43848r=dst IIS Stability:http://bugs.php.net/fix.php?id=43848r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43848r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43848r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43848r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43848r=mysqlcfg
#43812 [Asn]: 'password' parameter in my.cnf not honored even with mysqli_options()
ID: 43812 User updated by: graced at wingsnw dot com Reported By: graced at wingsnw dot com Status: Assigned Bug Type: MySQLi related Operating System: Debian lenny/sid PHP Version: 5.2.5 Assigned To: andrey New Comment: Clarification: Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6 'wadmin' was the username I was connecting with (I missed it when sanitizing my.cnf values), NOT my current login name (which is what PHP and mysql both default to otherwise). Just in case it matters. Previous Comments: [2008-01-11 03:32:02] graced at wingsnw dot com Description: my.cnf files allow the username/password/hostname and other connection information to be stored for later use. The Mysqli extension accepts a username from the file (overriding the default of the current login username) but not a password, thus it attempts to connect with no password even when a password is specified. The mysql command line client, when pointed at the file using --defaults-extra-file=path/to/file.cnf, successfully connects. Reproduce code: --- my.cnf contents: [client] host = localhost user = username password = topsecret PHP script: ?php error_reporting(E_ALL); $DB = mysqli_init(); $DB-options(MYSQLI_READ_DEFAULT_FILE, my.cnf); $DB-options(MYSQLI_READ_DEFAULT_GROUP, client); $DB-real_connect(); Expected result: A successful database connection. Actual result: -- Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6 -- Edit this bug report at http://bugs.php.net/?id=43812edit=1
#43849 [NEW]: date('YW', strtotime('2007-12-31')) return 200701
From: kiange at gmail dot com Operating system: Ubuntu PHP version: 5.2.5 PHP Bug Type: Date/time related Bug description: date('YW', strtotime('2007-12-31')) return 200701 Description: Enviornments: PHP 5.2.3-1ubuntu6.2 Reproduce code: --- echo date('YW', strtotime('2007-12-31')); // return 200701, maybe 200801 according to the reference page echo strftime(%Y%W,strtotime(2007-12-31)); // return 200753 Expected result: 200753 or 200801 Actual result: -- 200701 -- Edit bug report at http://bugs.php.net/?id=43849edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43849r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43849r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43849r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43849r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43849r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43849r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43849r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43849r=needscript Try newer version:http://bugs.php.net/fix.php?id=43849r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43849r=support Expected behavior:http://bugs.php.net/fix.php?id=43849r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43849r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43849r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43849r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43849r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43849r=dst IIS Stability:http://bugs.php.net/fix.php?id=43849r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43849r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43849r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43849r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43849r=mysqlcfg
#43849 [Opn-Bgs]: date('YW', strtotime('2007-12-31')) return 200701
ID: 43849 Updated by: [EMAIL PROTECTED] Reported By: kiange at gmail dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Ubuntu PHP Version: 5.2.5 New Comment: This is correct, the W shows the ISO week, which you need to match against the ISO year specifier (o - small O). ISO Week 2008-01 goes from Dec 31st to Jan 6th. This will return what you expect: echo date('Yo', strtotime('2007-12-31')), \n; strftime() would not be good to rely on, as the output might differ on other operating systems. Previous Comments: [2008-01-15 06:18:31] kiange at gmail dot com Description: Enviornments: PHP 5.2.3-1ubuntu6.2 Reproduce code: --- echo date('YW', strtotime('2007-12-31')); // return 200701, maybe 200801 according to the reference page echo strftime(%Y%W,strtotime(2007-12-31)); // return 200753 Expected result: 200753 or 200801 Actual result: -- 200701 -- Edit this bug report at http://bugs.php.net/?id=43849edit=1
#43850 [NEW]: Error #43105 still exists! File close problem
From: dg at artegic dot de Operating system: Solaris 10 x86 PHP version: 5.2CVS-2008-01-15 (snap) PHP Bug Type: Apache2 related Bug description: Error #43105 still exists! File close problem Description: PHP (php5.2-200801141730) is still not closing open files, resulting in an email-related error after a while...as mentioned in error #43105: Could not execute mail delivery program '/usr/lib/sendmail -t -i' lsof -u daemon|grep httpd|wc -l 3937 ...still growing... Using Apache 2.2.6, mpm-worker, Solaris 10 x86. -- Edit bug report at http://bugs.php.net/?id=43850edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43850r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43850r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43850r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43850r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43850r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43850r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43850r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43850r=needscript Try newer version:http://bugs.php.net/fix.php?id=43850r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43850r=support Expected behavior:http://bugs.php.net/fix.php?id=43850r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43850r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43850r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43850r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43850r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43850r=dst IIS Stability:http://bugs.php.net/fix.php?id=43850r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43850r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43850r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43850r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43850r=mysqlcfg
#41608 [Fbk-Opn]: Apache crash because of script
ID: 41608 User updated by: aigors at inbox dot lv Reported By: aigors at inbox dot lv -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 Assigned To: tony2001 New Comment: Yes, it appears that bug is in the snapshots also. Previous Comments: [2008-01-14 22:26:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-18 09:47:50] aigors at inbox dot lv Bug still exists in PHP 5.2.5. [2007-06-06 08:35:53] [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. [2007-06-06 07:44:20] aigors at inbox dot lv Description: Apache crash because of script containing set_error_handler function. Reproduce code: --- /***Main php file***/ ?php function MyErrorHandler($errno, $errstr, $errfile, $errline){ include_once('empty.php'); } set_error_handler(MyErrorHandler); include_once('blah.php'); echo('I am done'); ? /***blah.php file***/ ?php class Blah { function foo($value, $classname) { switch(strtolower($value['key'])) { default: $x = new $classname; } } } ? /***empty.php file - no content***/ Expected result: Should output I am done Actual result: -- Apache crash -- Edit this bug report at http://bugs.php.net/?id=41608edit=1