#38604 [NEW]: Memory leak in SimpleXML ?
From: apachephp at gmail dot com
Operating system: Linux
PHP version: 5.1.5
PHP Bug Type: SimpleXML related
Bug description: Memory leak in SimpleXML ?
Description:
I'm processing big XML file (1-10MB each) in loop.
Very soon free memory is near to zero and system starts swapping.
Reproduce code:
---
report as $reports)
{
//echo $reports->forumid."\n";
}
// var_dump($xml);
unset($xml);
} else {
exit('Failed to open test.xml.');
}
}
$files=file('files.txt');
foreach ($files as $file)
{
$file=chop($file);
echo "Processing $file\n";
ProcessFile($file);
}
?>
--
Edit bug report at http://bugs.php.net/?id=38604&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38604&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38604&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38604&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38604&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38604&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38604&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38604&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38604&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38604&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38604&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38604&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38604&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38604&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38604&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38604&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38604&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38604&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38604&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38604&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38604&r=mysqlcfg
#38594 [Fbk->Csd]: RegExp cause server crash
ID: 38594
User updated by: o dot veujoz at free dot fr
Reported By: o dot veujoz at free dot fr
-Status: Feedback
+Status: Closed
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.5
New Comment:
It perfectly works with the last build.
Thank you Tony (and the team) for the great job.
Previous Comments:
[2006-08-25 21:37:09] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-25 17:08:17] o dot veujoz at free dot fr
Description:
Since php 5.1.5 & 5.1.6 the following piece of code cause a server
crash, either on IIS 5.1 / Apache 2.0.59 (under windows XP, not tried
on other platform).
The regexp is from Pear::Wiki_Text library and was working with older
PHP versions (including 5.1.4).
Under IIS, I've got the message : "PHP has encountered a Stack
overflow"
No message with Apache...
I read a lot of things on this error (such as bad regexp writing), but
this time it is not a specific IIS case.
Removing the PCRE_DOTALL regexp option and the script works (but the
result is not what expected...).
I read the bug #28317 and was wondering if it wasn't the same
compilation problem ("Thus NO_RECURSE should be set in win32 compiler
options").
Best regards,
Olivier (from France, sorry for the spelling faults)
Reproduce code:
---
include_once("adodb/session/adodb-session2.php");
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
session_start();
';
$regex = ';^]*)?>((?:(?R)|.)*?)\n(\s|$);msi';
preg_match_all($regex, $text, $match);
print '';
print_r($match);
print '';
?>
--
Edit this bug report at http://bugs.php.net/?id=38594&edit=1
#38602 [NEW]: header( "HTTP/1.0 ..." ) does not change proto ver. Fix included.
From: tomsn at inetoffice dot com
Operating system: Linux
PHP version: 5.1.5
PHP Bug Type: Apache2 related
Bug description: header( "HTTP/1.0 ..." ) does not change proto ver. Fix
included.
Description:
Steps:
1. Create a php script with header("HTTP/1.0 200 OK") at the end. That
call is documented to change the protocol number of the response to 1.0.
2. Use mod_dumpio in Apache2 to observe the sent headers from any HTTP/1.1
request, or you can use Firefox Live HTTP Headers header watcher, or
whatever.
RESULT: Apache sends HTTP/1.1 200 OK as the response header.
EXPECT: Apache to respect your wishes and send HTTP/1.0 200 OK as the
response header.
DIAGNOSES:
The problem results from the way Apache2 tracks the pieces of the
resultant status line seperately. The httpd.h structure request_rec has
fields status_line, status, and proto_num. These are analyzed and combined
within Apache in a mystical and magical way. The fix to this bug is to give
it an updated proto_num and to send it a special apache_setenv().
DETAILS:
sapi/apache2handler/sapi_apache2(121) --
php_apache_sapi_send_headers()
Has the following code used to transmit the HTTP response status line to
Apache:
/* httpd requires that r->status_line is set to the first digit of
* the status-code: */
if (sline && strlen(sline) > 12 && strncmp(sline, "HTTP/1.", 7) == 0
&& sline[8] == ' ') {
ctx->r->status_line = apr_pstrdup(ctx->r->pool, sline + 9);
}
Insert into that code the following line just before the end curly:
ctx->r->proto_num = 1000 + (sline[7]-'0');
That funky 1000 + expression is how apache2 tracks HTTP protocol numbers
internally. See their HTTP_VERSION() macro.
NOW, although this added line of code sends Apache an accurate status line
protocol number, Apache is in the habit of ignoring it. To force Apache to
really use it, you can either code the following apache_setenv() into PHP
as a special case of send headers, or you can document for the user that
they need to call it from their script. The call is:
apache_setenv( "force-response-1.0", "true" );
I hope this is of some use to you. Thanks for all the excellent work in
building and maintaining PHP.
Reproduce code:
---
header("HTTP/1.0 200 OK");
Expected result:
Browser to receive this header:
HTTP/1.0 200 OK
Actual result:
--
Browser receives this header:
HTTP/1.1 200 OK
(notice the last 1 in /1.1)
--
Edit bug report at http://bugs.php.net/?id=38602&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38602&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38602&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38602&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38602&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38602&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38602&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38602&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38602&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38602&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38602&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38602&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38602&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38602&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38602&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38602&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38602&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38602&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38602&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38602&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38602&r=mysqlcfg
#38599 [Fbk->Opn]: Subpattern is not captured for backreference in some cases
ID: 38599 User updated by: pilotv at rambler dot ru Reported By: pilotv at rambler dot ru -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: All PHP Version: 4.4.4 New Comment: Sorry, I can not compile PHP myself here. But I tryed latest available for download version 5.1.6. This bug is still present in it. Previous Comments: [2006-08-25 21:38:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-08-25 21:02:59] pilotv at rambler dot ru Description: (Sorry for my english) Subpattern is not captured for backreference if it is followed by '?' and does not appear in subject string. Reproduce code: --- EOD; // Following RE works properly $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); // Following RE works wrong $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); ?> Expected result: // Produced by 1st RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) [2] => Array ( [0] => [1] => [2] => aaa ) ) Actual result: -- // Produced by 2nd RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) ) -- Edit this bug report at http://bugs.php.net/?id=38599&edit=1
#38600 [Opn->Fbk]: Infinite loop in preg_match
ID: 38600 Updated by: [EMAIL PROTECTED] Reported By: phillip dot berndt at googlemail dot com -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: Linux PHP Version: 5.1.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-08-25 21:14:47] phillip dot berndt at googlemail dot com Description: When executing the code below, the function won't return but loop forever (or do something else, I don't know). Reproduce code: --- Expected result: Something like that: [EMAIL PROTECTED] ~ $ time perl -e '$_="bla bla bla"; /(? Fatal error: Maximum execution time of 10 seconds exceeded in /home/pberndt/- on line 4 -- Edit this bug report at http://bugs.php.net/?id=38600&edit=1
#38599 [Opn->Fbk]: Subpattern is not captured for backreference in some cases
ID: 38599 Updated by: [EMAIL PROTECTED] Reported By: pilotv at rambler dot ru -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: All PHP Version: 4.4.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-08-25 21:02:59] pilotv at rambler dot ru Description: (Sorry for my english) Subpattern is not captured for backreference if it is followed by '?' and does not appear in subject string. Reproduce code: --- EOD; // Following RE works properly $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); // Following RE works wrong $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); ?> Expected result: // Produced by 1st RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) [2] => Array ( [0] => [1] => [2] => aaa ) ) Actual result: -- // Produced by 2nd RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) ) -- Edit this bug report at http://bugs.php.net/?id=38599&edit=1
#38594 [Opn->Fbk]: RegExp cause server crash
ID: 38594
Updated by: [EMAIL PROTECTED]
Reported By: o dot veujoz at free dot fr
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-08-25 17:08:17] o dot veujoz at free dot fr
Description:
Since php 5.1.5 & 5.1.6 the following piece of code cause a server
crash, either on IIS 5.1 / Apache 2.0.59 (under windows XP, not tried
on other platform).
The regexp is from Pear::Wiki_Text library and was working with older
PHP versions (including 5.1.4).
Under IIS, I've got the message : "PHP has encountered a Stack
overflow"
No message with Apache...
I read a lot of things on this error (such as bad regexp writing), but
this time it is not a specific IIS case.
Removing the PCRE_DOTALL regexp option and the script works (but the
result is not what expected...).
I read the bug #28317 and was wondering if it wasn't the same
compilation problem ("Thus NO_RECURSE should be set in win32 compiler
options").
Best regards,
Olivier (from France, sorry for the spelling faults)
Reproduce code:
---
include_once("adodb/session/adodb-session2.php");
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
session_start();
';
$regex = ';^]*)?>((?:(?R)|.)*?)\n(\s|$);msi';
preg_match_all($regex, $text, $match);
print '';
print_r($match);
print '';
?>
--
Edit this bug report at http://bugs.php.net/?id=38594&edit=1
#38587 [Opn->Fbk]: Error after moving from 4.4.2->4.4.4 "Notice:A session had already been started
ID: 38587 Updated by: [EMAIL PROTECTED] Reported By: jgantes at gmail dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows 2003R2 PHP Version: 4.4.4 Previous Comments: [2006-08-25 16:35:12] jgantes at gmail dot com We will attempt to move to PHP 5 as you have suggested. [2006-08-25 07:50:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-08-25 07:40:53] jgantes at gmail dot com Description: Ever since upgrading from 4.4.2 (both on Linux and Windows w/ Apache) we're receiving the following error: Notice: A session had already been started - ignoring session_start() We have already checked session.auto_start and this is off. In addition, I don't actually have two sessions initiating. Also, we've posted in several forums before stopping here. Note, that when I DOWNGRADE to version 4.4.2 this issue goes away as well. Is this a bug or feature by design? It sounds like other users have had this issue too in previous versions. Reproduce code: --- Expected result: Is this by design or a bug? If so, why does it keep changing back and forth? This was also true between previous versions of PHP. -- Edit this bug report at http://bugs.php.net/?id=38587&edit=1
#38592 [Opn->Bgs]: PDOStatement child classes cannot implement iterator
ID: 38592
Updated by: [EMAIL PROTECTED]
Reported By: php dot net at benjamin dot schulz dot name
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: linux
PHP Version: 5.2.0RC2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2006-08-25 16:05:55] php dot net at benjamin dot schulz dot name
Description:
classes that inherit PDOStatement cannot implement Iterator
Reproduce code:
---
class FOO extends PDOStatement implements Iterator
{
public function current() {}
public function key() {}
public function next() {}
public function rewind() {}
public function valid() {}
}
Actual result:
--
Fatal error: Class FOO could not implement interface Iterator in
Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=38592&edit=1
#38591 [Opn->Fbk]: Memory Leak when using pathinfo and DirectoryIterator __toString
ID: 38591 Updated by: [EMAIL PROTECTED] Reported By: rr at d2g dot org dot uk -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: win XP PHP Version: 5.1.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-08-25 15:19:24] rr at d2g dot org dot uk Description: When running the code below on PHP version 5.1.6. On what seems to be any directory with files in, have tested with my C:/ and C:/folder/. The code below is run from the Command Line to recreate the issue. This is only present when using __toString rather than ->getFileName() or ->getPathName functions of DirectoryIterator. A memory leak occours. Reproduce code: --- Expected result: Works. Actual result: -- Works, but has memory Leak. -- Edit this bug report at http://bugs.php.net/?id=38591&edit=1
#38600 [NEW]: Infinite loop in preg_match
From: phillip dot berndt at googlemail dot com Operating system: Linux PHP version: 5.1.5 PHP Bug Type: PCRE related Bug description: Infinite loop in preg_match Description: When executing the code below, the function won't return but loop forever (or do something else, I don't know). Reproduce code: --- Expected result: Something like that: [EMAIL PROTECTED] ~ $ time perl -e '$_="bla bla bla"; /(? Fatal error: Maximum execution time of 10 seconds exceeded in /home/pberndt/- on line 4 -- Edit bug report at http://bugs.php.net/?id=38600&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38600&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38600&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38600&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38600&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38600&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38600&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38600&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38600&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38600&r=support Expected behavior:http://bugs.php.net/fix.php?id=38600&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38600&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38600&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38600&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38600&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38600&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38600&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38600&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38600&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38600&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38600&r=mysqlcfg
#38597 [Opn->Csd]: preg_match with long match returns blanc page
ID: 38597
User updated by: koen dot devreeze at gmail dot com
Reported By: koen dot devreeze at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.5
New Comment:
Closing bug report
Previous Comments:
[2006-08-25 20:33:50] koen dot devreeze at gmail dot com
The problem is fixed in cvs snapshot of php 5.2.
Thanks.
[2006-08-25 20:21:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-25 19:59:49] koen dot devreeze at gmail dot com
Description:
When processing this code. The parsing ends on the preg_match
function.
$t has 475 characters in it. Remove one char and the script works
again.
PS.: This was also tested with php 5.1.4 on gentoo linux without any
problems.
Reproduce code:
---
$t =
"---";
$text = "
".$t."
Some text doesn't matter how long
";
//echo strlen($t);
$pattern = '/((.)*?)<(\/)?p>/';
preg_match($pattern, $text, $paragraphs) or die("died");
echo $paragraphs[0];
Expected result:
$t should be displayed no matter how many chars it has (though
considering limitation of PCRE).
Actual result:
--
Script ends on preg_match after a few seconds of 100% CPU load. No
errors no crashes.
--
Edit this bug report at http://bugs.php.net/?id=38597&edit=1
#38599 [NEW]: Subpattern is not captured for backreference in some cases
From: pilotv at rambler dot ru Operating system: All PHP version: 4.4.4 PHP Bug Type: PCRE related Bug description: Subpattern is not captured for backreference in some cases Description: (Sorry for my english) Subpattern is not captured for backreference if it is followed by '?' and does not appear in subject string. Reproduce code: --- EOD; // Following RE works properly $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); // Following RE works wrong $re='//iS'; preg_match_all($re,$str,$regs,PREG_SET_ORDER); print_r($regs); ?> Expected result: // Produced by 1st RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) [2] => Array ( [0] => [1] => [2] => aaa ) ) Actual result: -- // Produced by 2nd RE: Array ( [0] => Array ( [0] => [1] => " [2] => aaa ) [1] => Array ( [0] => [1] => ' [2] => aaa ) ) -- Edit bug report at http://bugs.php.net/?id=38599&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38599&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38599&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38599&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38599&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38599&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38599&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38599&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38599&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38599&r=support Expected behavior:http://bugs.php.net/fix.php?id=38599&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38599&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38599&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38599&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38599&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38599&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38599&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38599&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38599&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38599&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38599&r=mysqlcfg
#38596 [Opn->Fbk]: PHP segfaults on exit() with PDO prepared statements
ID: 38596
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-08-25 19:07:15] [EMAIL PROTECTED]
The problem also exists in PHP 5.2.0 RC1. The backtrace is identical
except for different line numbers:
#0 0x40402927 in mysql_more_results () from
/usr//lib/libmysqlclient.so.14
#1 0x0814bfb0 in free_statement (stmt=0x40793b54) at
/home/martin/src/php-5.2.0RC1/ext/pdo/pdo_stmt.c:2225
#2 0x082fd939 in zend_objects_store_free_object_storage
(objects=0x8477d78) at
/home/martin/src/php-5.2.0RC1/Zend/zend_objects_API.c:86
#3 0x082d4193 in shutdown_executor () at
/home/martin/src/php-5.2.0RC1/Zend/zend_execute_API.c:295
#4 0x082e1260 in zend_deactivate () at
/home/martin/src/php-5.2.0RC1/Zend/zend.c:839
#5 0x0829c678 in php_request_shutdown (dummy=0x0) at
/home/martin/src/php-5.2.0RC1/main/main.c:1300
#6 0x0835820e in main (argc=3, argv=0xbb64) at
/home/martin/src/php-5.2.0RC1/sapi/cli/php_cli.c:1250
[2006-08-25 18:46:14] [EMAIL PROTECTED]
Description:
[Note: This bug is against PHP 5.1.6, but the bug interface only offers
5.1.5.]
The code below makes PHP segfault at the time that exit() is called.
This happens with both CLI and Apache 2 (prefork). I'm using MySQL
4.1.11.
If the return value of prepare() is not assigned to a variable, the
script does not crash. Also it does not crash when omitting the exit()
call.
Reproduce code:
---
prepare("UPDATE entry SET id = ?");
exit();
}
}
$obj = new SomeClass;
$obj->doSomething(1);
Expected result:
No crash.
Actual result:
--
#0 0x4011c927 in mysql_more_results () from
/usr//lib/libmysqlclient.so.14
#1 0x08134329 in free_statement (stmt=0x84e351c) at
/home/martin/src/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#2 0x082a2349 in zend_objects_store_free_object_storage
(objects=0x83f60dc) at
/home/martin/src/php-5.1.6/Zend/zend_objects_API.c:86
#3 0x0828062f in shutdown_executor () at
/home/martin/src/php-5.1.6/Zend/zend_execute_API.c:281
#4 0x0828b074 in zend_deactivate () at
/home/martin/src/php-5.1.6/Zend/zend.c:854
#5 0x082513b6 in php_request_shutdown (dummy=0x0) at
/home/martin/src/php-5.1.6/main/main.c:1292
#6 0x082f0cc0 in main (argc=3, argv=0xbb84) at
/home/martin/src/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit this bug report at http://bugs.php.net/?id=38596&edit=1
#38597 [Fbk->Opn]: preg_match with long match returns blanc page
ID: 38597
User updated by: koen dot devreeze at gmail dot com
Reported By: koen dot devreeze at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.5
New Comment:
The problem is fixed in cvs snapshot of php 5.2.
Thanks.
Previous Comments:
[2006-08-25 20:21:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-25 19:59:49] koen dot devreeze at gmail dot com
Description:
When processing this code. The parsing ends on the preg_match
function.
$t has 475 characters in it. Remove one char and the script works
again.
PS.: This was also tested with php 5.1.4 on gentoo linux without any
problems.
Reproduce code:
---
$t =
"---";
$text = "
".$t."
Some text doesn't matter how long
";
//echo strlen($t);
$pattern = '/((.)*?)<(\/)?p>/';
preg_match($pattern, $text, $paragraphs) or die("died");
echo $paragraphs[0];
Expected result:
$t should be displayed no matter how many chars it has (though
considering limitation of PCRE).
Actual result:
--
Script ends on preg_match after a few seconds of 100% CPU load. No
errors no crashes.
--
Edit this bug report at http://bugs.php.net/?id=38597&edit=1
#38598 [NEW]: Query parameters are bound using wrong data type
From: michael dot walter at gmail dot com
Operating system: Windows XP
PHP version: 5.2.0RC2
PHP Bug Type: PDO related
Bug description: Query parameters are bound using wrong data type
Description:
Given a table post_stats with an 'id int IDENTITY(1,1) PRIMARY KEY'
column, the following query fails (see below). Is that expected, and
bindParam() to be used?
Reproduce code:
---
$pdo->prepare("SELECT * FROM (SELECT TOP 1 * FROM (SELECT TOP 1 * FROM
post_stats WHERE (id = ?) ORDER BY id ASC) AS temp1 ORDER BY id
DESC")->execute(array(1));
Expected result:
Nothing.
Actual result:
--
Exception: ...[SQL Server]Explicit conversion from data type text to int
is not allowed...
--
Edit bug report at http://bugs.php.net/?id=38598&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38598&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38598&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38598&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38598&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38598&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38598&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38598&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38598&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38598&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38598&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38598&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38598&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38598&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38598&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38598&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38598&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38598&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38598&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38598&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38598&r=mysqlcfg
#38597 [Opn->Fbk]: preg_match with long match returns blanc page
ID: 38597
Updated by: [EMAIL PROTECTED]
Reported By: koen dot devreeze at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.1.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2006-08-25 19:59:49] koen dot devreeze at gmail dot com
Description:
When processing this code. The parsing ends on the preg_match
function.
$t has 475 characters in it. Remove one char and the script works
again.
PS.: This was also tested with php 5.1.4 on gentoo linux without any
problems.
Reproduce code:
---
$t =
"---";
$text = "
".$t."
Some text doesn't matter how long
";
//echo strlen($t);
$pattern = '/((.)*?)<(\/)?p>/';
preg_match($pattern, $text, $paragraphs) or die("died");
echo $paragraphs[0];
Expected result:
$t should be displayed no matter how many chars it has (though
considering limitation of PCRE).
Actual result:
--
Script ends on preg_match after a few seconds of 100% CPU load. No
errors no crashes.
--
Edit this bug report at http://bugs.php.net/?id=38597&edit=1
#38597 [NEW]: preg_match with long match returns blanc page
From: koen dot devreeze at gmail dot com
Operating system: Windows XP
PHP version: 5.1.5
PHP Bug Type: PCRE related
Bug description: preg_match with long match returns blanc page
Description:
When processing this code. The parsing ends on the preg_match function.
$t has 475 characters in it. Remove one char and the script works again.
PS.: This was also tested with php 5.1.4 on gentoo linux without any
problems.
Reproduce code:
---
$t =
"---";
$text = "
".$t."
Some text doesn't matter how long
";
//echo strlen($t);
$pattern = '/((.)*?)<(\/)?p>/';
preg_match($pattern, $text, $paragraphs) or die("died");
echo $paragraphs[0];
Expected result:
$t should be displayed no matter how many chars it has (though considering
limitation of PCRE).
Actual result:
--
Script ends on preg_match after a few seconds of 100% CPU load. No errors
no crashes.
--
Edit bug report at http://bugs.php.net/?id=38597&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38597&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38597&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38597&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38597&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38597&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38597&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38597&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38597&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38597&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38597&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38597&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38597&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38597&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38597&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38597&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38597&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38597&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38597&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38597&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38597&r=mysqlcfg
#38596 [Opn]: PHP segfaults on exit() with PDO prepared statements
ID: 38596
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
The problem also exists in PHP 5.2.0 RC1. The backtrace is identical
except for different line numbers:
#0 0x40402927 in mysql_more_results () from
/usr//lib/libmysqlclient.so.14
#1 0x0814bfb0 in free_statement (stmt=0x40793b54) at
/home/martin/src/php-5.2.0RC1/ext/pdo/pdo_stmt.c:2225
#2 0x082fd939 in zend_objects_store_free_object_storage
(objects=0x8477d78) at
/home/martin/src/php-5.2.0RC1/Zend/zend_objects_API.c:86
#3 0x082d4193 in shutdown_executor () at
/home/martin/src/php-5.2.0RC1/Zend/zend_execute_API.c:295
#4 0x082e1260 in zend_deactivate () at
/home/martin/src/php-5.2.0RC1/Zend/zend.c:839
#5 0x0829c678 in php_request_shutdown (dummy=0x0) at
/home/martin/src/php-5.2.0RC1/main/main.c:1300
#6 0x0835820e in main (argc=3, argv=0xbb64) at
/home/martin/src/php-5.2.0RC1/sapi/cli/php_cli.c:1250
Previous Comments:
[2006-08-25 18:46:14] [EMAIL PROTECTED]
Description:
[Note: This bug is against PHP 5.1.6, but the bug interface only offers
5.1.5.]
The code below makes PHP segfault at the time that exit() is called.
This happens with both CLI and Apache 2 (prefork). I'm using MySQL
4.1.11.
If the return value of prepare() is not assigned to a variable, the
script does not crash. Also it does not crash when omitting the exit()
call.
Reproduce code:
---
prepare("UPDATE entry SET id = ?");
exit();
}
}
$obj = new SomeClass;
$obj->doSomething(1);
Expected result:
No crash.
Actual result:
--
#0 0x4011c927 in mysql_more_results () from
/usr//lib/libmysqlclient.so.14
#1 0x08134329 in free_statement (stmt=0x84e351c) at
/home/martin/src/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#2 0x082a2349 in zend_objects_store_free_object_storage
(objects=0x83f60dc) at
/home/martin/src/php-5.1.6/Zend/zend_objects_API.c:86
#3 0x0828062f in shutdown_executor () at
/home/martin/src/php-5.1.6/Zend/zend_execute_API.c:281
#4 0x0828b074 in zend_deactivate () at
/home/martin/src/php-5.1.6/Zend/zend.c:854
#5 0x082513b6 in php_request_shutdown (dummy=0x0) at
/home/martin/src/php-5.1.6/main/main.c:1292
#6 0x082f0cc0 in main (argc=3, argv=0xbb84) at
/home/martin/src/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit this bug report at http://bugs.php.net/?id=38596&edit=1
#32979 [Com]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
Comment by: stotty at tvnet dot hu
Reported By: mjpph at stardust dot fi
Status: Assigned
Bug Type: Streams related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2006-01-18 (dev)
Assigned To: wez
New Comment:
Bug is still present in 5.1.4
Previous Comments:
[2006-01-31 23:08:00] stotty at tvnet dot hu
I have compared the original socket operations code, and the one in the
xp_ssl.x file, and it seems that even in the non-ssl path the code is
not identical.
I have fixed four differences, two of which caused some functions to be
called twice, and two of which are casting to *(int*)
I do not claim to know the real cause for the bug, and how these
changes fix the problem, but they do, and they make the code more
consistent, and faster, so I think they should be committed.
Here is the patch that solves this problem form me (against 5.1.2)
cut here---
*** php-5.1.2/ext/openssl/xp_ssl.c 2006-01-01 13:50:10.0 +0100
--- php-5.1.2ssl/ext/openssl/xp_ssl.c 2006-01-31 23:00:58.0
+0100
***
*** 188,194
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
}
if (didwrite > 0) {
--- 188,195
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
! return didwrite;
}
if (didwrite > 0) {
***
*** 226,231
--- 227,233
else
{
nr_bytes = php_stream_socket_ops.read(stream, buf, count
TSRMLS_CC);
+ return nr_bytes;
}
if (nr_bytes > 0) {
***
*** 636,642
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *ret = (void*)sslsock->s.socket;
}
return SUCCESS;
--- 638,644
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *(int*)ret = (void*)sslsock->s.socket;
}
return SUCCESS;
***
*** 646,652
return FAILURE;
}
if (ret) {
! *ret = (void*)sslsock->s.socket;
}
return SUCCESS;
default:
--- 648,654
return FAILURE;
}
if (ret) {
! *(int*)ret = (void*)sslsock->s.socket;
}
return SUCCESS;
default:
cut here---
[2006-01-30 09:41:28] stotty at tvnet dot hu
I've done some testing, and this bug is definitely triggered by 64 bit+
SSL support.
Bug triggers:
FC4 64 bit + PHP5.1.2 (configure --with-openssl)
FC4 64 bit + PHP 5.1Jan 29 snapshot (configure --with-openssl)
Bug does not trigger:
FC4 64 bit + PHP 5.1.2 (configure)
FC4 64 bit + PHP 5.1Jan29 snapshot (configure)
FC4 32 bit + PHP 5.1.2 (configure --with-openssl)
FC4 32 bit + PHP 5.0.4-10.5 (stock FC RPM)
[2006-01-17 23:08:59] mjpph at stardust dot fi
Doesn't work with the php5.1-200601172130.tar.gz snapshot nor with
5.1.2.
[2005-11-07 00:08:49] [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-07-28 01:50:49] lew at mailduct dot com
wez -- the problems reported here are all due to a previously fixed bug
which has crept back into PHP. It has to do with how the PHP library
treats EOF under FreeBSD vs Linux.
You worked on this problem previously... please take a look at the
currently active Bug #32858 reported by me, as well as your prior fix
in Bug #25649.
Thanks
Lew Payne
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/32979
--
Edit this bug report at http://bugs.php.net/?id=32979&edit=1
#38596 [NEW]: PHP segfaults on exit() with PDO prepared statements
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 5.1.5
PHP Bug Type: PDO related
Bug description: PHP segfaults on exit() with PDO prepared statements
Description:
[Note: This bug is against PHP 5.1.6, but the bug interface only offers
5.1.5.]
The code below makes PHP segfault at the time that exit() is called. This
happens with both CLI and Apache 2 (prefork). I'm using MySQL 4.1.11.
If the return value of prepare() is not assigned to a variable, the script
does not crash. Also it does not crash when omitting the exit() call.
Reproduce code:
---
prepare("UPDATE entry SET id = ?");
exit();
}
}
$obj = new SomeClass;
$obj->doSomething(1);
Expected result:
No crash.
Actual result:
--
#0 0x4011c927 in mysql_more_results () from
/usr//lib/libmysqlclient.so.14
#1 0x08134329 in free_statement (stmt=0x84e351c) at
/home/martin/src/php-5.1.6/ext/pdo/pdo_stmt.c:2200
#2 0x082a2349 in zend_objects_store_free_object_storage
(objects=0x83f60dc) at
/home/martin/src/php-5.1.6/Zend/zend_objects_API.c:86
#3 0x0828062f in shutdown_executor () at
/home/martin/src/php-5.1.6/Zend/zend_execute_API.c:281
#4 0x0828b074 in zend_deactivate () at
/home/martin/src/php-5.1.6/Zend/zend.c:854
#5 0x082513b6 in php_request_shutdown (dummy=0x0) at
/home/martin/src/php-5.1.6/main/main.c:1292
#6 0x082f0cc0 in main (argc=3, argv=0xbb84) at
/home/martin/src/php-5.1.6/sapi/cli/php_cli.c:1246
--
Edit bug report at http://bugs.php.net/?id=38596&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38596&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38596&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38596&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38596&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38596&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38596&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38596&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38596&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38596&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38596&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38596&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38596&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38596&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38596&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38596&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38596&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38596&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38596&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38596&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38596&r=mysqlcfg
#38594 [NEW]: RegExp cause server crash
From: o dot veujoz at free dot fr
Operating system: Windows XP
PHP version: 5.1.5
PHP Bug Type: PCRE related
Bug description: RegExp cause server crash
Description:
Since php 5.1.5 & 5.1.6 the following piece of code cause a server crash,
either on IIS 5.1 / Apache 2.0.59 (under windows XP, not tried on other
platform).
The regexp is from Pear::Wiki_Text library and was working with older PHP
versions (including 5.1.4).
Under IIS, I've got the message : "PHP has encountered a Stack overflow"
No message with Apache...
I read a lot of things on this error (such as bad regexp writing), but
this time it is not a specific IIS case.
Removing the PCRE_DOTALL regexp option and the script works (but the
result is not what expected...).
I read the bug #28317 and was wondering if it wasn't the same compilation
problem ("Thus NO_RECURSE should be set in win32 compiler options").
Best regards,
Olivier (from France, sorry for the spelling faults)
Reproduce code:
---
include_once("adodb/session/adodb-session2.php");
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
ADOdb_Session::config($driver=\'mysql\', $host, $user, $password,
$database,$options=false);
session_start();
';
$regex = ';^]*)?>((?:(?R)|.)*?)\n(\s|$);msi';
preg_match_all($regex, $text, $match);
print '';
print_r($match);
print '';
?>
--
Edit bug report at http://bugs.php.net/?id=38594&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38594&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38594&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38594&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38594&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38594&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38594&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38594&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38594&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38594&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38594&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38594&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38594&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38594&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38594&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38594&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38594&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38594&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38594&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38594&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38594&r=mysqlcfg
#37682 [Asn->Csd]: ReflectionObject::getProperties() does not return dynamic properties
ID: 37682
Updated by: [EMAIL PROTECTED]
Reported By: ncosta at alum dot rpi dot edu
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 5.1.4
Assigned To: johannes
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.
Marcus fixed this couple of months ago in HEAD and 5_2
http://cvs.php.net/viewvc.cgi/php-src/ext/reflection/php_reflection.c?r1=1.164.2.33.2.7&r2=1.164.2.33.2.8&pathrev=PHP_5_2
Previous Comments:
[2006-06-02 19:30:25] [EMAIL PROTECTED]
Already on my personal todo :-)
[2006-06-02 17:31:01] ncosta at alum dot rpi dot edu
Description:
The method ReflectionObject::getProperties() fails to return
any dynamically-set properties of an object. The Reflection
API is aware of them, because they appear in an export (as
shown below) and are found by ReflectionObject::hasProperty(),
but they do not appear in the array returned by getProperties
(). There is no "getDynamicProperties()" method, and so
without specific documentation it stands to reason that
getProperties() should return ALL of an object's visible
properties, both compile-time and run-time.
Reproduce code:
---
class Foo
{
public $bar;
}
$p = new Foo;
$p->baz = 4;
$r = new ReflectionObject( $p );
Reflection::export( $r );
print_r( $r->getProperties() );
Expected result:
Object of class [ class Foo ] {
@@ /var/www/test.php 3-6
- Constants [0] {
}
- Static properties [0] {
}
- Static methods [0] {
}
- Properties [1] {
Property [ public $bar ]
}
- Dynamic properties [1] {
Property [ public $baz ]
}
- Methods [0] {
}
}
Array
(
[0] => ReflectionProperty Object
(
[name] => bar
[class] => Foo
)
[1] => ReflectionProperty Object
(
[name] => baz
[class] => Foo
)
)
Actual result:
--
Object of class [ class Foo ] {
@@ /var/www/test.php 3-6
- Constants [0] {
}
- Static properties [0] {
}
- Static methods [0] {
}
- Properties [1] {
Property [ public $bar ]
}
- Dynamic properties [1] {
Property [ public $baz ]
}
- Methods [0] {
}
}
Array
(
[0] => ReflectionProperty Object
(
[name] => bar
[class] => Foo
)
)
--
Edit this bug report at http://bugs.php.net/?id=37682&edit=1
#38595 [NEW]: XSLTProcessor::registerPHPFunctions() should be able to register callbacks
From: goliath dot mailinglist at gmx dot de
Operating system: Linux
PHP version: 5.1.5
PHP Bug Type: Feature/Change Request
Bug description: XSLTProcessor::registerPHPFunctions() should be able to
register callbacks
Description:
XSLTProcessor::registerPHPFunctions() has very limited use. It is only
possible to register static callable functions.
Some nicer API would be:
$xslt = new XSLTProcessor()
$xslt->registerPHPFunctions(array(
'func1' => 'functionblah',
'func2' => array('class', 'method'),
'func3' => array($obj, 'method') // this would be the real advantage
));
Or even better:
$xslt->registerPHPFunction('func1', 'functionblah');
$xslt->registerPHPFunction('func2', array('class', 'method'));
$xslt->registerPHPFunction('func3', array($obj, 'method'));
$xslt->removePHPFunction('func1');
This would be similar to the set/get/removeParameter-API
btw.: Your CAPCHA only works with cookies enabled, that really sucks.
Reproduce code:
---
None, not possible
Expected result:
Be able to have instance-methods as callbacks for the XSLTProcessor.
(Note: Not global accessibly objects)
Actual result:
--
Not possible
--
Edit bug report at http://bugs.php.net/?id=38595&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38595&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38595&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38595&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38595&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38595&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38595&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38595&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38595&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38595&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38595&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38595&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38595&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38595&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38595&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38595&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38595&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38595&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38595&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38595&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38595&r=mysqlcfg
#38587 [Fbk->Opn]: Error after moving from 4.4.2->4.4.4 "Notice:A session had already been started
ID: 38587 User updated by: jgantes at gmail dot com Reported By: jgantes at gmail dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: Windows 2003R2 PHP Version: 4.4.4 New Comment: We will attempt to move to PHP 5 as you have suggested. Previous Comments: [2006-08-25 07:50:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-08-25 07:40:53] jgantes at gmail dot com Description: Ever since upgrading from 4.4.2 (both on Linux and Windows w/ Apache) we're receiving the following error: Notice: A session had already been started - ignoring session_start() We have already checked session.auto_start and this is off. In addition, I don't actually have two sessions initiating. Also, we've posted in several forums before stopping here. Note, that when I DOWNGRADE to version 4.4.2 this issue goes away as well. Is this a bug or feature by design? It sounds like other users have had this issue too in previous versions. Reproduce code: --- Expected result: Is this by design or a bug? If so, why does it keep changing back and forth? This was also true between previous versions of PHP. -- Edit this bug report at http://bugs.php.net/?id=38587&edit=1
#38593 [NEW]: feature request for an attribute that contains the current cursor position
From: php dot net at benjamin dot schulz dot name Operating system: PHP version: 5.2.0RC2 PHP Bug Type: PDO related Bug description: feature request for an attribute that contains the current cursor position Description: an attribute or an argument that gives current cursor position (count of fetched rows) would be usefulk Reproduce code: --- PDOStatement::getAttribute(PDO::ATTR_CURSOR_POSITION)) -- Edit bug report at http://bugs.php.net/?id=38593&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38593&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38593&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38593&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38593&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38593&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38593&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38593&r=support Expected behavior:http://bugs.php.net/fix.php?id=38593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38593&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38593&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38593&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38593&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38593&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38593&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38593&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38593&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38593&r=mysqlcfg
#38592 [NEW]: PDOStatement child classes cannot implement iterator
From: php dot net at benjamin dot schulz dot name
Operating system: linux
PHP version: 5.2.0RC2
PHP Bug Type: PDO related
Bug description: PDOStatement child classes cannot implement iterator
Description:
classes that inherit PDOStatement cannot implement Iterator
Reproduce code:
---
class FOO extends PDOStatement implements Iterator
{
public function current() {}
public function key() {}
public function next() {}
public function rewind() {}
public function valid() {}
}
Actual result:
--
Fatal error: Class FOO could not implement interface Iterator in Unknown
on line 0
--
Edit bug report at http://bugs.php.net/?id=38592&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38592&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38592&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38592&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38592&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38592&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38592&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38592&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38592&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38592&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38592&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38592&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38592&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38592&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38592&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38592&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38592&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38592&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38592&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38592&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38592&r=mysqlcfg
#38577 [Com]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 Comment by: judas dot iscariote at gmail dot com Reported By: php at diptyque dot net Status: Open Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: PHP5 produces the same effects for you ? Previous Comments: [2006-08-25 13:39:31] [EMAIL PROTECTED] Reclassified as Apache-related issue. [2006-08-25 13:32:22] php at diptyque dot net I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. [2006-08-24 16:20:24] php at diptyque dot net Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php int(72208) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) int(18) =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. [2006-08-24 15:04:03] php at diptyque dot net I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58902) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58914) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38591 [NEW]: Memory Leak when using pathinfo and DirectoryIterator __toString
From: rr at d2g dot org dot uk Operating system: win XP PHP version: 5.1.5 PHP Bug Type: *Directory/Filesystem functions Bug description: Memory Leak when using pathinfo and DirectoryIterator __toString Description: When running the code below on PHP version 5.1.6. On what seems to be any directory with files in, have tested with my C:/ and C:/folder/. The code below is run from the Command Line to recreate the issue. This is only present when using __toString rather than ->getFileName() or ->getPathName functions of DirectoryIterator. A memory leak occours. Reproduce code: --- Expected result: Works. Actual result: -- Works, but has memory Leak. -- Edit bug report at http://bugs.php.net/?id=38591&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38591&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38591&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38591&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38591&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38591&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38591&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38591&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38591&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38591&r=support Expected behavior:http://bugs.php.net/fix.php?id=38591&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38591&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38591&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38591&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38591&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38591&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38591&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38591&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38591&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38591&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38591&r=mysqlcfg
#38541 [Asn->Csd]: go-pear.php in PHP-4.4.4 not yet OK
ID: 38541 Updated by: [EMAIL PROTECTED] Reported By: axel dot azerty at laposte dot net -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 4.4.4 Assigned To: edink New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-08-22 08:34:25] axel dot azerty at laposte dot net Replacing the go-pear.php script by the one found at http://go-pear.org solved this problem. [2006-08-22 08:33:10] axel dot azerty at laposte dot net Here's the installation log : C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4.4.4-Win32>go-peatr 'go-peatr' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes. C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4.4.4-Win32>go-pear.bat Welcome to go-pear! Go-pear will install the 'pear' command and all the files needed by it. This command is your tool for PEAR installation and maintenance. Use 'php PEAR\go-pear.php local' to install a local copy of PEAR. Go-pear also lets you download and install the PEAR packages bundled with PHP: MDB2, Net_Socket, Net_SMTP, Mail, XML_Parser, PHPUnit. If you wish to abort, press Control-C now, or press Enter to continue: HTTP proxy (http://user:[EMAIL PROTECTED]:port), or Enter for none:: 'C:\Documents' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes. *WARNING* We found php.exe under C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4.4.4-Win32\cli\php.ex e, it uses an unknown SAPI. PEAR commandline tool has not been tested with it, if you have a CLI (or CGI) php.exe available, we strongly recommand to use it. Below is a suggested file layout for your new PEAR installation. To change individual locations, type the number in front of the directory. Type 'all' to change all of them or simply press Enter to accept these locations. 1. Installation prefix : C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4.4.4-Win 32 2. Binaries directory: $prefix 3. PHP code directory ($php_dir) : $prefix\pear 4. Documentation base directory : $php_dir\docs 5. Data base directory : $php_dir\data 6. Tests base directory : $php_dir\tests 7. Temporary files directory : $prefix\temp 8. php.exe path : C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4.4.4-Win 32\cli\php.exe 1-8, 'all' or Enter to continue: The following PEAR packages are bundled with PHP: MDB2, Net_Socket, Net_SMTP, Mail, XML_Parser, PHPUnit. Would you like to install these as well? [Y/n] : Loading zlib: ok Using local package: PEAR-stable..ok Using local package: Archive_Tar-stableok Using local package: Console_Getopt-stableok Using local package: XML_RPC-stableok Bootstrapping: PEAR...(remote) http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> ViewVC Exception An Exception Has Occurred Python Traceback Traceback (most recent call last): File "/usr/local/viewvc-1.1-dev/lib/viewvc.py", line 3623, in main request.run_viewvc() File "/usr/local/viewvc-1.1-dev/lib/viewvc.py", line 388, in run_viewvc self.view_func(self) File "/usr/local/viewvc-1.1-dev/lib/viewvc.py", line 2122, in view_checkout fp, revision = request.repos.openfile(path, rev) File "/usr/local/viewvc-1.1-dev/lib/vclib/bincvs/__init__.py", line 134, in openfile filename, revision = _parse_co_header(fp) File "/usr/local/viewvc-1.1-dev/lib/vclib/bincvs/__init__.py", line 549, in _parse_co_header raise COMalformedOutput, "Unable to find revision in co output stream" COMalformedOutput: Unable to find revision in co output stream ok Bootstrapping: Archive_Tar(local) ok Bootstrapping: Console_Getopt.(remote) ok Downloading package: MDB2.ok Downloading package: Net_Socket...ok Downloading package: Net_SMTP.ok Downloading package: Mail.ok Downloading package: XML_Parser...ok Downloading package: PHPUnit..ok Fatal error: Undefined class name 'pear' in C:\Documents and Settings\Administrateur\Mes documents\php-4.4.4-Win32\php-4 .4.4-Win32\PEAR\go-pear.php on line 747 Appuyez sur une touche pour continuer... [2006-08-22 08:27:52] [EMAIL PROTECTED] >I h
#38577 [Opn]: ini settings leak between virtual hosts with Apache 1.3
ID: 38577 Updated by: [EMAIL PROTECTED] -Summary: Changing internal character encoding affects function overloading Reported By: php at diptyque dot net Status: Open -Bug Type: mbstring related +Bug Type: Apache related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: Reclassified as Apache-related issue. Previous Comments: [2006-08-25 13:32:22] php at diptyque dot net I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. [2006-08-24 16:20:24] php at diptyque dot net Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php int(72208) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) int(18) =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. [2006-08-24 15:04:03] php at diptyque dot net I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58902) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58914) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) [2006-08-24 12:41:06] [EMAIL PROTECTED] Right, int(19) is what I get on Linux and FreeBSD 5.4. 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#38577 [Opn]: Changing internal character encoding affects function overloading
ID: 38577 User updated by: php at diptyque dot net Reported By: php at diptyque dot net Status: Open Bug Type: mbstring related Operating System: FreeBSD 4.4 PHP Version: 4.4.4 New Comment: I forgot to mention that mbstring.func_overload is enabled on a per-vhost basis for some other web sites I'm hosting on this platform. Previous Comments: [2006-08-24 16:20:24] php at diptyque dot net Agreed but I'm not making things up, you know. Something is obviously wrong on my Apache 1.3.34 setup. Could this be a conflict with some extension or Apache module? Of course, no opcode cache is running. Any tip welcome. This weird behavior has been plaguing me for 2 months now and rebuilding PHP doesn't seem to help. I wrote a second test case which demonstrates that function overloading is effectively taking place sporadically while running under apache SAPI -- strlen() may accept the optional encoding argument (!?) as shown in the script output below. http://www.diptyque.net/bugs/mbinfo2.php http://www.diptyque.net/bugs/mbinfo2.phps ; source code =begin [diptyque] % GET http://www.diptyque.net/bugs/mbinfo2.php int(72208) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) int(18) =end If I do run the same script through PHP CLI or FastCGI, I get the following expected warnings: PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 17 PHP Warning: Wrong parameter count for strlen() in /path/to/htdocs/bugs/mbinfo2.php on line 25 [2006-08-24 15:15:31] [EMAIL PROTECTED] Please try with minimal configuration (like ./configure --enable-mbstring) and PHP CLI. If you're still able to reproduce it, you're likely to be the only person who can help you, since I really doubt anyone else can do it. [2006-08-24 15:04:03] php at diptyque dot net I moved mbstring function overload initial setting (6) from my php.ini to specific virtual hosts configuration sections but to no avail. It would seem that some Apache processes get it right while others get it wrong (!) This is quite weird -- for example, process #58902 returns int(18) while #58914 returns int(19). [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58902) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(18) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) [diptyque] % GET http://localhost/bugs/mbinfo2.php int(58914) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(5) "UTF-8" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) -- bool(true) string(10) "ISO-8859-1" string(10) "ISO-8859-1" string(1) "0" string(19) "Méthodes de codage" int(19) [2006-08-24 12:41:06] [EMAIL PROTECTED] Right, int(19) is what I get on Linux and FreeBSD 5.4. [2006-08-24 12:33:17] php at diptyque dot net Oops, my mistake. You should swap Expected and Actual results. Actual result is int(18) !? Expected result is int(19). 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/38577 -- Edit this bug report at http://bugs.php.net/?id=38577&edit=1
#37602 [Asn->Csd]: crash in COM_DOTNET when releasing typelib in php_com_typelibrary_dtor
ID: 37602
Updated by: [EMAIL PROTECTED]
Reported By: olek at neurosoft dot pl
-Status: Assigned
+Status: Closed
Bug Type: COM related
Operating System: Windows
PHP Version: 5.1.4
Assigned To: edink
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-05-29 15:00:51] [EMAIL PROTECTED]
Edin, the patch looks good, but I don't think I can test in on Linux.
Check it out, please.
[2006-05-29 14:25:02] olek at neurosoft dot pl
I suppose this bug belongs to "COM related" category rather than
"Reproducible crash". Sorry for my mistake.
[2006-05-26 14:37:23] olek at neurosoft dot pl
Description:
Crash caused by bug in function: php_com_typelibrary_dtor in module:
ext/com_dotnet/com_typeinfo.c
Patch is following:
--- php-5.1.4/ext/com_dotnet/com_typeinfo.c 2006-01-01
12:50:00.0 +0100
+++ php_build/php-5.1.4/ext/com_dotnet/com_typeinfo.c 2006-05-26
15:57:02.0 +0200
@@ -220,7 +220,7 @@
/* Type-library stuff */
void php_com_typelibrary_dtor(void *pDest)
{
- ITypeLib *Lib = *(ITypeLib**)pDest;
+ ITypeLib *Lib = (ITypeLib*)pDest;
ITypeLib_Release(Lib);
}
--
Edit this bug report at http://bugs.php.net/?id=37602&edit=1
#38580 [Asn->Bgs]: Can't resolve external character entities
ID: 38580
Updated by: [EMAIL PROTECTED]
Reported By: dandrikop at cosmote dot gr
-Status: Assigned
+Status: Bogus
Bug Type: DOM XML related
Operating System: Fedora Core 5
PHP Version: 5.1.5
Assigned To: rrichards
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
entities are only resolved/expanded (if requested) when the tree is
being loaded into DOM; otherwise entity references are contained within
the document. Sincde you are creating a document, entity references are
added.
Previous Comments:
[2006-08-24 10:49:41] dandrikop at cosmote dot gr
This is the "clickatell.dtd" file:
[2006-08-24 10:47:18] [EMAIL PROTECTED]
Warning: DOMDocument::validate(): I/O warning : failed to load external
entity "clickatell.dtd" in /tmp/1.php on line 33
Warning: DOMDocument::validate(): Could not load the external subset
"clickatell.dtd" in /tmp/1.php on line 33
[2006-08-24 10:30:51] dandrikop at cosmote dot gr
Description:
The PHP DOM extension cannot resolve entities declared in an external
DTD file.
Reproduce code:
---
createDocumentType( 'clickAPI', null,
'clickatell.dtd' );
$xml_request = $imp->createDocument( null, null, $dtd );
$xml_request->version = '1.0';
$xml_request->encoding = 'ISO-8859-1';
$xml_request->formatOutput = true;
$xml_request->resolveExternals = true;
$xml_request->substituteEntities = true;
$xml_request->standalone = false;
// Create the tag 'clickAPI'.
$clickAPI = $xml_request->appendChild( new DOMElement(
'clickAPI' ) );
// Create the tag 'sendMsg'.
$sendMsg = $clickAPI->appendChild( new DOMElement( 'sendMsg' )
);
// Add elements under the 'auth' tag.
$sendMsg->appendChild( new DOMElement( 'session_id',
'a' ) );
$sendMsg->appendChild( new DOMElement( 'text', "Test &testme;"
) );
$sendMsg->appendChild( new DOMElement( 'to', '30697888' )
);
if( $xml_request->validate() ){
echo "OK\n";
} else {
echo "Not OK!\n";
}
echo "\n" . $xml_request->saveXML() . "\n";
?>
Expected result:
a
Test HELLO
30697888
Actual result:
--
a
Test &testme;
30697888
--
Edit this bug report at http://bugs.php.net/?id=38580&edit=1
#38589 [Csd->Bgs]: fwrite() writes some extra '\'
ID: 38589
User updated by: tennysonvarghese at gmail dot com
Reported By: tennysonvarghese at gmail dot com
-Status: Closed
+Status: Bogus
Bug Type: *General Issues
Operating System: Debian linux 2.6.15-1-686
PHP Version: 4.4.4
New Comment:
ok
Previous Comments:
[2006-08-25 11:47:20] tennysonvarghese at gmail dot com
i'm sorry.. i understand its not a bug..
i turn off the magic quotes and now its alright..
magic_quotes_gpc = Off
[2006-08-25 11:46:38] [EMAIL PROTECTED]
Not PHP problem -> bogus.
[2006-08-25 11:38:55] tennysonvarghese at gmail dot com
thanks for the help.. i put off the magic quotes as you suggest.. now i
get the solution
[2006-08-25 08:56:45] [EMAIL PROTECTED]
Turn off magic_quotes.
[2006-08-25 08:24:39] tennysonvarghese at gmail dot com
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a
'\' for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i
write in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit this bug report at http://bugs.php.net/?id=38589&edit=1
#38589 [Bgs->Csd]: fwrite() writes some extra '\'
ID: 38589
User updated by: tennysonvarghese at gmail dot com
Reported By: tennysonvarghese at gmail dot com
-Status: Bogus
+Status: Closed
Bug Type: *General Issues
Operating System: Debian linux 2.6.15-1-686
PHP Version: 4.4.4
New Comment:
i'm sorry.. i understand its not a bug..
i turn off the magic quotes and now its alright..
magic_quotes_gpc = Off
Previous Comments:
[2006-08-25 11:46:38] [EMAIL PROTECTED]
Not PHP problem -> bogus.
[2006-08-25 11:38:55] tennysonvarghese at gmail dot com
thanks for the help.. i put off the magic quotes as you suggest.. now i
get the solution
[2006-08-25 08:56:45] [EMAIL PROTECTED]
Turn off magic_quotes.
[2006-08-25 08:24:39] tennysonvarghese at gmail dot com
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a
'\' for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i
write in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit this bug report at http://bugs.php.net/?id=38589&edit=1
#38589 [Csd->Bgs]: fwrite() writes some extra '\'
ID: 38589
Updated by: [EMAIL PROTECTED]
Reported By: tennysonvarghese at gmail dot com
-Status: Closed
+Status: Bogus
Bug Type: *General Issues
Operating System: Debian linux 2.6.15-1-686
PHP Version: 4.4.4
New Comment:
Not PHP problem -> bogus.
Previous Comments:
[2006-08-25 11:38:55] tennysonvarghese at gmail dot com
thanks for the help.. i put off the magic quotes as you suggest.. now i
get the solution
[2006-08-25 08:56:45] [EMAIL PROTECTED]
Turn off magic_quotes.
[2006-08-25 08:24:39] tennysonvarghese at gmail dot com
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a
'\' for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i
write in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit this bug report at http://bugs.php.net/?id=38589&edit=1
#38589 [Bgs->Csd]: fwrite() writes some extra '\'
ID: 38589
User updated by: tennysonvarghese at gmail dot com
Reported By: tennysonvarghese at gmail dot com
-Status: Bogus
+Status: Closed
Bug Type: *General Issues
Operating System: Debian linux 2.6.15-1-686
PHP Version: 4.4.4
New Comment:
thanks for the help.. i put off the magic quotes as you suggest.. now i
get the solution
Previous Comments:
[2006-08-25 08:56:45] [EMAIL PROTECTED]
Turn off magic_quotes.
[2006-08-25 08:24:39] tennysonvarghese at gmail dot com
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a
'\' for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i
write in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit this bug report at http://bugs.php.net/?id=38589&edit=1
#38590 [Csd->Bgs]: PDO Mysql returns garbage value for float column
ID: 38590
Updated by: [EMAIL PROTECTED]
Reported By: mark-phpbugs at vectrex dot org dot uk
-Status: Closed
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
Not PHP problem -> bogus.
Previous Comments:
[2006-08-25 10:02:15] mark-phpbugs at vectrex dot org dot uk
I think this is caused by the MySQL client library and server being
(somewhat) incompatible versions.
I've upgraded the MySQL client and server to 5.0.24 and the problem has
gone away.
[2006-08-25 08:47:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Can't reproduce both with 5.2 and 5.1.5.
[2006-08-25 08:37:28] mark-phpbug at vectrex dot org dot uk
Using MySQL 5.0.20 and
PDO Driver for MySQL, client library version5.0.22
[2006-08-25 08:33:40] mark-phpbugs at vectrex dot org dot uk
Description:
When selecting from a FLOAT column, PDO returns garbage instead of the
right value.
Tested in PHP 5.1.2 and 5.1.6; both fail in similar ways.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$db->exec("CREATE TEMPORARY TABLE test ( num FLOAT NOT NULL)");
$db->exec("INSERT INTO test VALUES (1.5)");
$st = $db->query("SELECT * FROM test");
$row = $st->fetch(PDO::FETCH_ASSOC);
var_dump($row);
?>
Expected result:
array(1) {
["num"]=>
string(12) "1.5"
}
Actual result:
--
array(1) {
["num"]=>
string(12) "-2.87989e-05"
}
Also other incorrect values; it seems nondeterministic.
--
Edit this bug report at http://bugs.php.net/?id=38590&edit=1
#38590 [Fbk->Csd]: PDO Mysql returns garbage value for float column
ID: 38590
User updated by: mark-phpbugs at vectrex dot org dot uk
Reported By: mark-phpbugs at vectrex dot org dot uk
-Status: Feedback
+Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
I think this is caused by the MySQL client library and server being
(somewhat) incompatible versions.
I've upgraded the MySQL client and server to 5.0.24 and the problem has
gone away.
Previous Comments:
[2006-08-25 08:47:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Can't reproduce both with 5.2 and 5.1.5.
[2006-08-25 08:37:28] mark-phpbug at vectrex dot org dot uk
Using MySQL 5.0.20 and
PDO Driver for MySQL, client library version5.0.22
[2006-08-25 08:33:40] mark-phpbugs at vectrex dot org dot uk
Description:
When selecting from a FLOAT column, PDO returns garbage instead of the
right value.
Tested in PHP 5.1.2 and 5.1.6; both fail in similar ways.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$db->exec("CREATE TEMPORARY TABLE test ( num FLOAT NOT NULL)");
$db->exec("INSERT INTO test VALUES (1.5)");
$st = $db->query("SELECT * FROM test");
$row = $st->fetch(PDO::FETCH_ASSOC);
var_dump($row);
?>
Expected result:
array(1) {
["num"]=>
string(12) "1.5"
}
Actual result:
--
array(1) {
["num"]=>
string(12) "-2.87989e-05"
}
Also other incorrect values; it seems nondeterministic.
--
Edit this bug report at http://bugs.php.net/?id=38590&edit=1
#38589 [Opn->Bgs]: fwrite() writes some extra '\'
ID: 38589
Updated by: [EMAIL PROTECTED]
Reported By: tennysonvarghese at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Debian linux 2.6.15-1-686
PHP Version: 4.4.4
New Comment:
Turn off magic_quotes.
Previous Comments:
[2006-08-25 08:24:39] tennysonvarghese at gmail dot com
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a
'\' for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i
write in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit this bug report at http://bugs.php.net/?id=38589&edit=1
#38590 [Opn->Fbk]: PDO Mysql returns garbage value for float column
ID: 38590
Updated by: [EMAIL PROTECTED]
Reported By: mark-phpbugs at vectrex dot org dot uk
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Can't reproduce both with 5.2 and 5.1.5.
Previous Comments:
[2006-08-25 08:37:28] mark-phpbug at vectrex dot org dot uk
Using MySQL 5.0.20 and
PDO Driver for MySQL, client library version5.0.22
[2006-08-25 08:33:40] mark-phpbugs at vectrex dot org dot uk
Description:
When selecting from a FLOAT column, PDO returns garbage instead of the
right value.
Tested in PHP 5.1.2 and 5.1.6; both fail in similar ways.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$db->exec("CREATE TEMPORARY TABLE test ( num FLOAT NOT NULL)");
$db->exec("INSERT INTO test VALUES (1.5)");
$st = $db->query("SELECT * FROM test");
$row = $st->fetch(PDO::FETCH_ASSOC);
var_dump($row);
?>
Expected result:
array(1) {
["num"]=>
string(12) "1.5"
}
Actual result:
--
array(1) {
["num"]=>
string(12) "-2.87989e-05"
}
Also other incorrect values; it seems nondeterministic.
--
Edit this bug report at http://bugs.php.net/?id=38590&edit=1
#38589 [NEW]: fwrite() writes some extra '\'
From: tennysonvarghese at gmail dot com
Operating system: Debian linux 2.6.15-1-686
PHP version: 4.4.4
PHP Bug Type: *General Issues
Bug description: fwrite() writes some extra '\'
Description:
fwrite() prepends '\' if is there any '," or \ . PHP tries to write a '\'
for every inclusion of the above characters.
Reproduce code:
---
Expected result:
i expect to remove the extra slash('\') and get the file as what i write
in the text area.
Actual result:
--
this is \\\'\\\' test
--
Edit bug report at http://bugs.php.net/?id=38589&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38589&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38589&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38589&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38589&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38589&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38589&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38589&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38589&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38589&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38589&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38589&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38589&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38589&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38589&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38589&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38589&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38589&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38589&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38589&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38589&r=mysqlcfg
#38588 [Opn->Bgs]: Default value of extension_dir in php.ini is wrong
ID: 38588 Updated by: [EMAIL PROTECTED] Reported By: gmtfn at yahoo dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP PHP Version: 5.1.5 New Comment: Bug #26581 contains a nice explanation of why this was not changed. Previous Comments: [2006-08-25 08:17:51] gmtfn at yahoo dot com Description: extension_dir in php.ini is set to "./", by default. Since extension DLLs are located in ext directory in the distributed package, this value should be "./ext/" to reduce installation time. And pretty much the same request was filed for version 4.3.4 (http://bugs.php.net/bug.php?id=26581&edit=2). I hope the resolution will be different this time. You're supplying a default value anyway, so why not make it so that the distributed package works out of the box? -- Edit this bug report at http://bugs.php.net/?id=38588&edit=1
#38590 [Com]: PDO Mysql returns garbage value for float column
ID: 38590
Comment by: mark-phpbug at vectrex dot org dot uk
Reported By: mark-phpbugs at vectrex dot org dot uk
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.5
New Comment:
Using MySQL 5.0.20 and
PDO Driver for MySQL, client library version5.0.22
Previous Comments:
[2006-08-25 08:33:40] mark-phpbugs at vectrex dot org dot uk
Description:
When selecting from a FLOAT column, PDO returns garbage instead of the
right value.
Tested in PHP 5.1.2 and 5.1.6; both fail in similar ways.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$db->exec("CREATE TEMPORARY TABLE test ( num FLOAT NOT NULL)");
$db->exec("INSERT INTO test VALUES (1.5)");
$st = $db->query("SELECT * FROM test");
$row = $st->fetch(PDO::FETCH_ASSOC);
var_dump($row);
?>
Expected result:
array(1) {
["num"]=>
string(12) "1.5"
}
Actual result:
--
array(1) {
["num"]=>
string(12) "-2.87989e-05"
}
Also other incorrect values; it seems nondeterministic.
--
Edit this bug report at http://bugs.php.net/?id=38590&edit=1
#38590 [NEW]: PDO Mysql returns garbage value for float column
From: mark-phpbugs at vectrex dot org dot uk
Operating system: Linux
PHP version: 5.1.5
PHP Bug Type: PDO related
Bug description: PDO Mysql returns garbage value for float column
Description:
When selecting from a FLOAT column, PDO returns garbage instead of the
right value.
Tested in PHP 5.1.2 and 5.1.6; both fail in similar ways.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$db->exec("CREATE TEMPORARY TABLE test ( num FLOAT NOT NULL)");
$db->exec("INSERT INTO test VALUES (1.5)");
$st = $db->query("SELECT * FROM test");
$row = $st->fetch(PDO::FETCH_ASSOC);
var_dump($row);
?>
Expected result:
array(1) {
["num"]=>
string(12) "1.5"
}
Actual result:
--
array(1) {
["num"]=>
string(12) "-2.87989e-05"
}
Also other incorrect values; it seems nondeterministic.
--
Edit bug report at http://bugs.php.net/?id=38590&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38590&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38590&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38590&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38590&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38590&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38590&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38590&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38590&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38590&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38590&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38590&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38590&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38590&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38590&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38590&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38590&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38590&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38590&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38590&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38590&r=mysqlcfg
#38588 [NEW]: Default value of extension_dir in php.ini is wrong
From: gmtfn at yahoo dot com Operating system: Windows XP PHP version: 5.1.5 PHP Bug Type: *Configuration Issues Bug description: Default value of extension_dir in php.ini is wrong Description: extension_dir in php.ini is set to "./", by default. Since extension DLLs are located in ext directory in the distributed package, this value should be "./ext/" to reduce installation time. And pretty much the same request was filed for version 4.3.4 (http://bugs.php.net/bug.php?id=26581&edit=2). I hope the resolution will be different this time. You're supplying a default value anyway, so why not make it so that the distributed package works out of the box? -- Edit bug report at http://bugs.php.net/?id=38588&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38588&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38588&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38588&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38588&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38588&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38588&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38588&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38588&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38588&r=support Expected behavior:http://bugs.php.net/fix.php?id=38588&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38588&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38588&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38588&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38588&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38588&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38588&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38588&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38588&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38588&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38588&r=mysqlcfg
#38587 [Opn->Fbk]: Error after moving from 4.4.2->4.4.4 "Notice:A session had already been started
ID: 38587 Updated by: [EMAIL PROTECTED] Reported By: jgantes at gmail dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows 2003R2 PHP Version: 4.4.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-08-25 07:40:53] jgantes at gmail dot com Description: Ever since upgrading from 4.4.2 (both on Linux and Windows w/ Apache) we're receiving the following error: Notice: A session had already been started - ignoring session_start() We have already checked session.auto_start and this is off. In addition, I don't actually have two sessions initiating. Also, we've posted in several forums before stopping here. Note, that when I DOWNGRADE to version 4.4.2 this issue goes away as well. Is this a bug or feature by design? It sounds like other users have had this issue too in previous versions. Reproduce code: --- Expected result: Is this by design or a bug? If so, why does it keep changing back and forth? This was also true between previous versions of PHP. -- Edit this bug report at http://bugs.php.net/?id=38587&edit=1
#38587 [NEW]: Error after moving from 4.4.2->4.4.4 "Notice:A session had already been started
From: jgantes at gmail dot com Operating system: Windows 2003R2 PHP version: 4.4.4 PHP Bug Type: Session related Bug description: Error after moving from 4.4.2->4.4.4 "Notice:A session had already been started Description: Ever since upgrading from 4.4.2 (both on Linux and Windows w/ Apache) we're receiving the following error: Notice: A session had already been started - ignoring session_start() We have already checked session.auto_start and this is off. In addition, I don't actually have two sessions initiating. Also, we've posted in several forums before stopping here. Note, that when I DOWNGRADE to version 4.4.2 this issue goes away as well. Is this a bug or feature by design? It sounds like other users have had this issue too in previous versions. Reproduce code: --- Expected result: Is this by design or a bug? If so, why does it keep changing back and forth? This was also true between previous versions of PHP. -- Edit bug report at http://bugs.php.net/?id=38587&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38587&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38587&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38587&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38587&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38587&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38587&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38587&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38587&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38587&r=support Expected behavior:http://bugs.php.net/fix.php?id=38587&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38587&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38587&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38587&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38587&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38587&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38587&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38587&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38587&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38587&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38587&r=mysqlcfg
#38586 [Opn->Bgs]: mktime has some problem for some day.
ID: 38586 Updated by: [EMAIL PROTECTED] Reported By: ziyunxiao at gmail dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: WiNXP PHP Version: 5.1.5 New Comment: We are happy to tell you that you just discovered Daylight Savings Time. For more information see: http://webexhibits.org/daylightsaving/b.html Instead of using mktime/date consider using gmmktime and gmdate which do not suffer from DST. . Previous Comments: [2006-08-25 00:01:35] ziyunxiao at gmail dot com Description: day Oct 30 has 9 seconds a day. I only test year 2005,2006,2007 in Version is php 5.1.4 and 5.1.6. I didn't install 5.1.5. the result is right on php 4.4.3 Reproduce code: --- "; ?> Expected result: seconds:86400 Actual result: -- seconds:9 -- Edit this bug report at http://bugs.php.net/?id=38586&edit=1
