#39612 [NEW]: closeCursor() does not allow SQLite 2 statement to resume
From: randy at rcs-comp dot com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: PDO related Bug description: closeCursor() does not allow SQLite 2 statement to resume Description: The documentation for PDOStatement::closeCursor(): frees up the connection to the server so that other SQL statements may be issued, but leaves the statement in a state that enables it to be executed again. When using PDO with a SQLite 3 connection, this works as intended. However, when trying to resume with a SQLite 2 connection, fetch() returns FALSE. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test2.php.txt Expected result: 4 arrays of the first row of data: >php simple_pdo_test2.php Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Actual result: -- The last call to fetch() returns FALSE >php simple_pdo_test2.php Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) bool(false) -- Edit bug report at http://bugs.php.net/?id=39612&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39612&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39612&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39612&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39612&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39612&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39612&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39612&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39612&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39612&r=support Expected behavior:http://bugs.php.net/fix.php?id=39612&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39612&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39612&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39612&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39612&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39612&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39612&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39612&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39612&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39612&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39612&r=mysqlcfg
#39611 [Opn]: Use of CURLOPT_NOBODY yields a 404 inexplicably
ID: 39611 User updated by: asbo at iserv dot net Reported By: asbo at iserv dot net Status: Open Bug Type: cURL related Operating System: Windows XP Professional PHP Version: 5.2.0 New Comment: I thought I'd clarify a bit more; the following line: curl_setopt($ch, CURLOPT_HEADER, true); is extraneous. If I remove this line and and the HTTP response code using curl_getinfo(), I'm still getting a 404. Using NOBODY(true) in addition to RETURNTRANSFER(false) may seem redundant, but RETURNTRANSFER(false) [as well as nothing except the URL set] alone still has cURL dumping the remote page into the output buffer. Previous Comments: [2006-11-24 05:15:28] asbo at iserv dot net Description: I'm running a default PHP 5.2.0 installation on Apache 2.0.55, XP Pro. Using cURL, the introduction of the CURLOPT_NOBODY setting results in cURL receiving a 404 page instead of the actual web page. In my understanding, the NOBODY setting shouldn't change the actual HTTP request at all, and therefore I should the same headers regardless of NOBODY being set or not. It doesn't seem like I'm missing something important -- feel free to correct me. Reproduce code: --- http://video.google.com/videoplay?docid=1384277706451157121'); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLOPT_NOBODY, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, false); echo curl_exec($ch); curl_close($ch); ?> Expected result: HTTP/1.1 200 OK Set-Cookie: sloc=en Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Cache-control: private Date: Fri, 24 Nov 2006 04:41:12 GMT Server: GFE/1.3 http://www.w3.org/TR/html4/loose.dtd";> (... etc) Actual result: -- HTTP/1.1 404 Not Found Set-Cookie: sloc=en Content-Type: text/html; charset=UTF-8 Content-Length: 141 Cache-control: private Date: Fri, 24 Nov 2006 04:49:49 GMT Server: GFE/1.3 -- Edit this bug report at http://bugs.php.net/?id=39611&edit=1
#39611 [NEW]: Use of CURLOPT_NOBODY yields a 404 inexplicably
From: asbo at iserv dot net Operating system: Windows XP Professional PHP version: 5.2.0 PHP Bug Type: cURL related Bug description: Use of CURLOPT_NOBODY yields a 404 inexplicably Description: I'm running a default PHP 5.2.0 installation on Apache 2.0.55, XP Pro. Using cURL, the introduction of the CURLOPT_NOBODY setting results in cURL receiving a 404 page instead of the actual web page. In my understanding, the NOBODY setting shouldn't change the actual HTTP request at all, and therefore I should the same headers regardless of NOBODY being set or not. It doesn't seem like I'm missing something important -- feel free to correct me. Reproduce code: --- http://video.google.com/videoplay?docid=1384277706451157121'); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLOPT_NOBODY, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, false); echo curl_exec($ch); curl_close($ch); ?> Expected result: HTTP/1.1 200 OK Set-Cookie: sloc=en Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Cache-control: private Date: Fri, 24 Nov 2006 04:41:12 GMT Server: GFE/1.3 http://www.w3.org/TR/html4/loose.dtd";> (... etc) Actual result: -- HTTP/1.1 404 Not Found Set-Cookie: sloc=en Content-Type: text/html; charset=UTF-8 Content-Length: 141 Cache-control: private Date: Fri, 24 Nov 2006 04:49:49 GMT Server: GFE/1.3 -- Edit bug report at http://bugs.php.net/?id=39611&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39611&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39611&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39611&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39611&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39611&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39611&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39611&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39611&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39611&r=support Expected behavior:http://bugs.php.net/fix.php?id=39611&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39611&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39611&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39611&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39611&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39611&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39611&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39611&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39611&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39611&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39611&r=mysqlcfg
#39601 [Fbk->Csd]: $GLOBALS superglobal and ${ {$ string variable parsing inconsistencies
ID: 39601
User updated by: jkloske at itee dot uq dot edu dot au
Reported By: jkloske at itee dot uq dot edu dot au
-Status: Feedback
+Status: Closed
Bug Type: Strings related
Operating System: Centos
PHP Version: 4.4.4
New Comment:
can't test linux, but windows php5 latest cvs snap doesn't suffer this
problem.
perhaps it's just a problem with php4 or our older version of it that
was fixed but not as a result of a bug report.
thanks!
Previous Comments:
[2006-11-23 10:05:59] [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-11-23 07:23:31] jkloske at itee dot uq dot edu dot au
Description:
The $GLOBALS superglobal when referenced inside a string using ${
(which is not strictly legal for PHP syntax, but which seems to work in
most other situations) doesn't appear to exist (it evaluates to an empty
string).
As soon as $GLOBALS is referenced anywhere else in that same scope via
either a direct expression or correctly inside a string using {$, even
if this occurs after the incorrect reference using ${ in a string, all
${ references work.
Very short example is included, to demonstrate, run as is, then run
with the commented out line uncommented.
I don't know that this is specifically a bug, but it does seem
inconsistent and potentially problematic, and at the very least should
be documented :)
I'm really sorry to report this with my version of PHP (4.3.11) but I
am not authorized to upgrade the version on the server, merely use it.
Reproduce code:
---
";
//$okayIwill = $GLOBALS['READMEIFYOUCAN'];
echo "${GLOBALS['READMEIFYOUCAN']}";
?>
Expected result:
A)
This line should appear twice!
This line should appear twice!
B)
Since this isn't strictly the correct format of {$, I would also accept
it printing out:
${GLOBALS['READMEIFYOUCAN']}
or perhaps some other strange PHP error type output or partially
printed versions of that string.
Actual result:
--
now uncomment the commented out line, and you see:
This line should appear twice!
This line should appear twice!
This seems to indicate that as long as $GLOBALS is referenced outside a
string, it works anywhere in the scope, even before it was first
referenced.
Note if you change either of the ${ inside the strings to {$ they both
work, regardless of the order.
--
Edit this bug report at http://bugs.php.net/?id=39601&edit=1
#39607 [NEW]: preg_match_all Segmentation fault
From: dimanjy23 at mail dot ru Operating system: Linux Fedora Core 5 PHP version: 5.2.0 PHP Bug Type: PCRE related Bug description: preg_match_all Segmentation fault Description: I installed the latest snapshot of PHP 5.2.0-dev compilen 2006-11-22. Sometimes (not always) preg_match_all couses the "Segmentation fault" error while processing some content. Reproduce code: --- http://makl.ru/content.txt";); // Regexp $pattern="/]*>((.(?!\/form>))+)<\/form>/si"; $res = array(); preg_match_all($pattern,$content,$res); echo "\n\nDone!"; var_dump($res); ?> Expected result: Expecting the part of text from content.txt between ... tags. Actual result: -- Start Segmentation fault -- Edit bug report at http://bugs.php.net/?id=39607&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39607&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39607&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39607&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39607&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39607&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39607&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39607&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39607&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39607&r=support Expected behavior:http://bugs.php.net/fix.php?id=39607&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39607&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39607&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39607&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39607&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39607&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39607&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39607&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39607&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39607&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39607&r=mysqlcfg
#39604 [WFx]: File Upload Original name problem if it is with apostrophe.
ID: 39604 User updated by: akocherhan at sagasoft dot com Reported By: akocherhan at sagasoft dot com Status: Wont fix Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.4.4 New Comment: Okay, I understand your point. I'll discuss with my chief about this way. Thanks. Previous Comments: [2006-11-23 10:40:26] [EMAIL PROTECTED] If you manage to find the patch for it (from either HEAD or PHP_5_2), we can have a look at it. [2006-11-23 10:38:52] akocherhan at sagasoft dot com So as I understand it is not possible to fix this bug in php version 4. And we need to move to php version 5, recheck/retest/rewrite all php scripts? Maybe there is another way? Thanks for understanding. [2006-11-23 10:32:32] [EMAIL PROTECTED] I don't think so. PHP4 is in maintainance state and only critical/security problems are fixed there. This is neither critical nor security related. [2006-11-23 10:27:08] akocherhan at sagasoft dot com Thanks, but my web site use php version 4. Is this bug fixed for php version 4? [2006-11-23 10:23:00] [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 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/39604 -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39564 [Opn->Bgs]: PDO::errorInfo() returns inconsistent information
ID: 39564
Updated by: [EMAIL PROTECTED]
Reported By: php dot bugreport dot tarpit at spamgourmet dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Windows 98SE and XP/SP1
PHP Version: 5.2.0
New Comment:
First of all, you're using zErr returned by sqlite3_exec(), of course
it's right.
Second, sqlite3_step() doesn't return error code (as sqlite3_exec()
does), it returns SQLITE_ERROR instead and the error code is fetched
using sqlite3_errcode(db).
Previous Comments:
[2006-11-23 23:11:26] php dot bugreport dot tarpit at spamgourmet dot
com
I tried the following code using SQLite 3.3.7:
#include
#include
#include
#include
int main()
{ sqlite3 *db;
sqlite3_stmt *stm;
int rc;
char *sqli, *sqlp, *zErr;
const char *tail;
rc = sqlite3_open("bugtest.db", &db);
if(rc) { fprintf(stdout, "Can't open database: %s\n",
sqlite3_errmsg(db)); exit(255); }
sqli = "Insert Into TEST (Key, Text) Values (1, 'Test1')";
sqlp = "Insert Into TEST (Key, Text) Values (?, ?)";
rc = sqlite3_exec(db, sqli, NULL, NULL, &zErr);
if(rc) { fprintf(stdout, "exec(): %i - %s\n", rc, zErr); }
rc = sqlite3_prepare(db, sqlp, strlen(sqlp), &stm, &tail);
if(rc) { fprintf(stdout, "prepare(): %i - %s\n", rc, zErr); }
rc = sqlite3_bind_int(stm, 1, 1);
if(rc) { fprintf(stdout, "bind_int(): %i - %s\n", rc, zErr); }
rc = sqlite3_bind_text(stm, 2, "Test1", 5, SQLITE_STATIC);
if(rc) { fprintf(stdout, "bind_text(): %i - %s\n", rc, zErr); }
rc = sqlite3_step(stm);
if(rc) { fprintf(stdout, "step(): %i - %s\n", rc, zErr); }
sqlite3_finalize(stm); sqlite3_close(db); return 0; }
With result:
exec(): 19 - PRIMARY KEY must be unique
step(): 1 - PRIMARY KEY must be unique
Yes, sqlite3_step() does return the wrong errorcode - that is a bug in
SQLite. But it still returns the correct message, which appears to get
lost somewhere.
[2006-11-21 22:10:34] [EMAIL PROTECTED]
These two methods use different SQLite functions to execute queries,
which report different errors. And that is the reason I can hardly
imagine why it's PDO fault.
[2006-11-21 22:04:52] php dot bugreport dot tarpit at spamgourmet dot
com
Original category was "SQLite related" - because that is the only part
of PDO I use. Since the error is obviously not in SQLite (which reports
the correct errors), but in PDO (which reports different errors
depending on the use of PDO::exec() or PDOStatement::execute()
functions), category "PDO related" would be better.
[2006-11-21 09:29:12] [EMAIL PROTECTED]
SQLite inconsistencies should be reported to SQLite developers.
[2006-11-20 23:56:21] php dot bugreport dot tarpit at spamgourmet dot
com
Description:
When retrieving error information with PDO::errorInfo() after an
SQL-insert causing a constraint violation results are inconsistent
depending on the form of the statement: PDO::exec() or
PDOStatement::execute().
Reproduce code:
---
SQL to create database followed by sample PHP:
CREATE TABLE TEST ( Key Integer Primary Key, Text Char(20) Not Null );
CREATE UNIQUE INDEX iTEST On TEST ( Text );
SetAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);
$dbh_test->Exec("Insert Into TEST (Key, Text) Values (1, 'Test1')");
$pdo_error=$dbh_test->ErrorInfo();
Print "\n$pdo_error[0] $pdo_error[1] $pdo_error[2] :: 1, 'Test1'\n";
$sql="Insert Into TEST (Key, Text) Values (:key, :text)";
$sq_insert=$dbh_test->Prepare($sql);
$sq_insert->BindParam(':key', $key); $sq_insert->BindParam(':text',
$text);
$key=1; $text="Test1"; $sq_insert->Execute();
$pdo_error=$sq_insert->ErrorInfo();
Print "\n$pdo_error[0] $pdo_error[1] $pdo_error[2] :: $key, $text\n";
Exit(0);
?>
Expected result:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
Actual result:
--
PHP 5.1.6:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 PRIMARY KEY must be unique :: 1, Test1
PHP 5.2.0:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 SQL logic error or missing database :: 1, Test1
5CVS-2006-11-18:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 SQL logic error or missing database :: 1, Test1
--
Edit this bug report at http://bugs.php.net/?id=39564&edit=1
#39564 [Bgs->Opn]: PDO::errorInfo() returns inconsistent information
ID: 39564
User updated by: php dot bugreport dot tarpit at spamgourmet dot com
Reported By: php dot bugreport dot tarpit at spamgourmet dot com
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Windows 98SE and XP/SP1
PHP Version: 5.2.0
New Comment:
I tried the following code using SQLite 3.3.7:
#include
#include
#include
#include
int main()
{ sqlite3 *db;
sqlite3_stmt *stm;
int rc;
char *sqli, *sqlp, *zErr;
const char *tail;
rc = sqlite3_open("bugtest.db", &db);
if(rc) { fprintf(stdout, "Can't open database: %s\n",
sqlite3_errmsg(db)); exit(255); }
sqli = "Insert Into TEST (Key, Text) Values (1, 'Test1')";
sqlp = "Insert Into TEST (Key, Text) Values (?, ?)";
rc = sqlite3_exec(db, sqli, NULL, NULL, &zErr);
if(rc) { fprintf(stdout, "exec(): %i - %s\n", rc, zErr); }
rc = sqlite3_prepare(db, sqlp, strlen(sqlp), &stm, &tail);
if(rc) { fprintf(stdout, "prepare(): %i - %s\n", rc, zErr); }
rc = sqlite3_bind_int(stm, 1, 1);
if(rc) { fprintf(stdout, "bind_int(): %i - %s\n", rc, zErr); }
rc = sqlite3_bind_text(stm, 2, "Test1", 5, SQLITE_STATIC);
if(rc) { fprintf(stdout, "bind_text(): %i - %s\n", rc, zErr); }
rc = sqlite3_step(stm);
if(rc) { fprintf(stdout, "step(): %i - %s\n", rc, zErr); }
sqlite3_finalize(stm); sqlite3_close(db); return 0; }
With result:
exec(): 19 - PRIMARY KEY must be unique
step(): 1 - PRIMARY KEY must be unique
Yes, sqlite3_step() does return the wrong errorcode - that is a bug in
SQLite. But it still returns the correct message, which appears to get
lost somewhere.
Previous Comments:
[2006-11-21 22:10:34] [EMAIL PROTECTED]
These two methods use different SQLite functions to execute queries,
which report different errors. And that is the reason I can hardly
imagine why it's PDO fault.
[2006-11-21 22:04:52] php dot bugreport dot tarpit at spamgourmet dot
com
Original category was "SQLite related" - because that is the only part
of PDO I use. Since the error is obviously not in SQLite (which reports
the correct errors), but in PDO (which reports different errors
depending on the use of PDO::exec() or PDOStatement::execute()
functions), category "PDO related" would be better.
[2006-11-21 09:29:12] [EMAIL PROTECTED]
SQLite inconsistencies should be reported to SQLite developers.
[2006-11-20 23:56:21] php dot bugreport dot tarpit at spamgourmet dot
com
Description:
When retrieving error information with PDO::errorInfo() after an
SQL-insert causing a constraint violation results are inconsistent
depending on the form of the statement: PDO::exec() or
PDOStatement::execute().
Reproduce code:
---
SQL to create database followed by sample PHP:
CREATE TABLE TEST ( Key Integer Primary Key, Text Char(20) Not Null );
CREATE UNIQUE INDEX iTEST On TEST ( Text );
SetAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);
$dbh_test->Exec("Insert Into TEST (Key, Text) Values (1, 'Test1')");
$pdo_error=$dbh_test->ErrorInfo();
Print "\n$pdo_error[0] $pdo_error[1] $pdo_error[2] :: 1, 'Test1'\n";
$sql="Insert Into TEST (Key, Text) Values (:key, :text)";
$sq_insert=$dbh_test->Prepare($sql);
$sq_insert->BindParam(':key', $key); $sq_insert->BindParam(':text',
$text);
$key=1; $text="Test1"; $sq_insert->Execute();
$pdo_error=$sq_insert->ErrorInfo();
Print "\n$pdo_error[0] $pdo_error[1] $pdo_error[2] :: $key, $text\n";
Exit(0);
?>
Expected result:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
Actual result:
--
PHP 5.1.6:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 PRIMARY KEY must be unique :: 1, Test1
PHP 5.2.0:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 SQL logic error or missing database :: 1, Test1
5CVS-2006-11-18:
23000 19 PRIMARY KEY must be unique :: 1, 'Test1'
HY000 1 SQL logic error or missing database :: 1, Test1
--
Edit this bug report at http://bugs.php.net/?id=39564&edit=1
#39610 [Opn->Bgs]: Number of return Modular_arithmetic is negative..
ID: 39610 Updated by: [EMAIL PROTECTED] Reported By: ocracy at msn dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: windows PHP Version: 4.4.4 New Comment: # php -r 'var_dump(pow(2,31));' is greater than PHP_INT_MAX, so it cannot be represented as positive integer when casted to int. Hence "Note: Remainder $a % $b is negative for negative $a." http://www.php.net/manual/en/language.operators.arithmetic.php Previous Comments: [2006-11-23 22:59:01] ocracy at msn dot com Description: Number of return Modular_arithmetic must be positive in general but i tryed high nubmer like(2^30++) in Modular_arithmetic, PHP gave me negative nubmer... example: x=2^31, y=x%20, y = negative in PHP Reproduce code: --- Expected result: Negative numbers.. Like -6 -38 -44 .. .. Actual result: -- nubmer of return will be positive.. -- Edit this bug report at http://bugs.php.net/?id=39610&edit=1
#39417 [Com]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
Comment by: yatiohi at ideopolis dot gr
Reported By: konstantin dot ryabitsev at mcgill dot ca
Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Linux, Windows
PHP Version: 5.2.0
New Comment:
We are at least two persons on earth :-)
[EMAIL PROTECTED] tmp]$ php -version
PHP 5.1.6 (cli) (built: Nov 2 2006 16:46:15)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED] tmp]$ rpm -q libtidy
libtidy-0.99.0-11.20051025.fc6
[EMAIL PROTECTED] tmp]$ rpm -q php-tidy
php-tidy-5.1.6-1.fc6
[EMAIL PROTECTED] tmp]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED] tmp]$ php tidy.php
Previous Comments:
[2006-11-23 22:28:28] [EMAIL PROTECTED]
You seem to be the only (unlucky?) person on the earth able to
reproduce it, hence it doesn't seem to me as a problem of PHP.
If you want to keep this report open and not to be marked as bogus,
please provide at least some info required to reproduce it.
I'm very excited that Python bindings work fine for you. So does
ext/tidy for me.
[2006-11-23 22:11:45] konstantin dot ryabitsev at mcgill dot ca
It's great that it's working fine for you. However, it's not working
for me, and I can now add Windows into the pile:
http://blues.mcgill.ca/~icon/misc/not-making-it-up.png
So, now reproduced on 3 different linux distros, and 2 different
platforms.
I'm not sure how much more I can do to convince you that I'm not making
this up.
I have tried the exact same parameters from tidy python bindings. I do
not see the same error. The error only seems to occur when I use php
bindings.
If you are going to close this bug, please don't close as bogus. This
bug is real.
[2006-11-23 21:11:31] [EMAIL PROTECTED]
Works just fine here using both libtidy-CVS and default SuSE version
(built on Mar 19 2005).
Please update libtidy to the latest CVS, and if that doesn't help, harp
on this to libtidy developers.
# ./sapi/cli/php /tmp/2.php
# cat /tmp/2.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[2006-11-23 20:59:58] konstantin dot ryabitsev at mcgill dot ca
[EMAIL PROTECTED]:[~]$ rpm -q libtidy
libtidy-0:0.99.0-11.20051025.fc6.i386
(this is the latest released -- I have previously built the latest CVS
of libtidy while testing this bug, but there was no difference in the
end-result)
[2006-11-23 20:56:35] [EMAIL PROTECTED]
Which Tidy version are you using?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#20260 [Com]: Cookies set on Remote Host but not on localhost
ID: 20260
Comment by: asbo at iserv dot net
Reported By: m_e_brown at hotmail dot com
Status: No Feedback
Bug Type: Session related
Operating System: Windows 2000 Professional
PHP Version: 4.2.1
New Comment:
I'm experiencing an similar issue, but it's conditional based on how I
access the server (WinXP, Apache v2.0.55, PHP 5.2.0 [module]).
When I connect to the server using an IP address (127.0.0.1,
192.168.0.*), cookies work fine. However, if I use a NetBIOS name
(asbo, localhost -- which should resolve cleanly into an IP address) it
doesn't seem that cookies are set properly. This has been tested in both
Firefox 1.5.0.8/2.0 and Internet Explorer 6.0 and all exhibit identical
behavior in testing.
Obviously this isn't a huge issue -- I get the expected behavior on my
internet server and using IP addresses as started above -- but as this
report hadn't even received feedback I thought I'd throw my two cents
in.
Previous Comments:
[2002-11-21 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-11-05 09:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-05 09:55:11] m_e_brown at hotmail dot com
I installed php as a module on apache2 folllowing the standard set up.
I have a user logon screen which works on a remote server but not when
developing and testing on a stand alone machine that is a local server.
I hold the username and passwords on mysql and ask the user for their
username and password which gets sent to another .php page which first
of all sets the following cookies
setcookie("email",$email,time()+1800);
setcookie ("password",$password,time()+1800);
Then verifies this against the database and if succesfull redirects to
the 'members area' where the cookies are set again otherwise it
redirects to a logout page. [Which is where i get sent on the local
machine]
I have tried the following formats for the setcookie and all
combinations including setting the expiry time to 8000.
setcookie("email",$_POST["email"],time()+1800);
setcookie ("password",$_POST["password"],time()+1800);
setcookie("email",$email,"time()+1800");
setcookie ("password",$password,"time()+1800");
The database authentication is being succeful, it is just that the
cookies are not being set on the local machine, as when I hit the
members area I set the email value to another variable, set the cooies
as before, then alert() the old value [before the $email was reset by
the new setcookie() command.
I have the following lines set in my php.ini
register_globals = On
variables_order = "EGPCS"
Do you have any idea why my local machine is not setting the cookies???
Please help
--
Edit this bug report at http://bugs.php.net/?id=20260&edit=1
#39610 [NEW]: Number of return Modular_arithmetic is negative..
From: ocracy at msn dot com Operating system: windows PHP version: 4.4.4 PHP Bug Type: *General Issues Bug description: Number of return Modular_arithmetic is negative.. Description: Number of return Modular_arithmetic must be positive in general but i tryed high nubmer like(2^30++) in Modular_arithmetic, PHP gave me negative nubmer... example: x=2^31, y=x%20, y = negative in PHP Reproduce code: --- Expected result: Negative numbers.. Like -6 -38 -44 .. .. Actual result: -- nubmer of return will be positive.. -- Edit bug report at http://bugs.php.net/?id=39610&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39610&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39610&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39610&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39610&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39610&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39610&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39610&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39610&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39610&r=support Expected behavior:http://bugs.php.net/fix.php?id=39610&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39610&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39610&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39610&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39610&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39610&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39610&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39610&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39610&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39610&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39610&r=mysqlcfg
#39417 [Opn->Fbk]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
Updated by: [EMAIL PROTECTED]
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Linux, Windows
PHP Version: 5.2.0
New Comment:
You seem to be the only (unlucky?) person on the earth able to
reproduce it, hence it doesn't seem to me as a problem of PHP.
If you want to keep this report open and not to be marked as bogus,
please provide at least some info required to reproduce it.
I'm very excited that Python bindings work fine for you. So does
ext/tidy for me.
Previous Comments:
[2006-11-23 22:11:45] konstantin dot ryabitsev at mcgill dot ca
It's great that it's working fine for you. However, it's not working
for me, and I can now add Windows into the pile:
http://blues.mcgill.ca/~icon/misc/not-making-it-up.png
So, now reproduced on 3 different linux distros, and 2 different
platforms.
I'm not sure how much more I can do to convince you that I'm not making
this up.
I have tried the exact same parameters from tidy python bindings. I do
not see the same error. The error only seems to occur when I use php
bindings.
If you are going to close this bug, please don't close as bogus. This
bug is real.
[2006-11-23 21:11:31] [EMAIL PROTECTED]
Works just fine here using both libtidy-CVS and default SuSE version
(built on Mar 19 2005).
Please update libtidy to the latest CVS, and if that doesn't help, harp
on this to libtidy developers.
# ./sapi/cli/php /tmp/2.php
# cat /tmp/2.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[2006-11-23 20:59:58] konstantin dot ryabitsev at mcgill dot ca
[EMAIL PROTECTED]:[~]$ rpm -q libtidy
libtidy-0:0.99.0-11.20051025.fc6.i386
(this is the latest released -- I have previously built the latest CVS
of libtidy while testing this bug, but there was no difference in the
end-result)
[2006-11-23 20:56:35] [EMAIL PROTECTED]
Which Tidy version are you using?
[2006-11-23 20:51:44] konstantin dot ryabitsev at mcgill dot ca
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Bgs->Opn]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
User updated by: konstantin dot ryabitsev at mcgill dot ca
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
-Operating System: Linux
+Operating System: Linux, Windows
PHP Version: 5.2.0
New Comment:
It's great that it's working fine for you. However, it's not working
for me, and I can now add Windows into the pile:
http://blues.mcgill.ca/~icon/misc/not-making-it-up.png
So, now reproduced on 3 different linux distros, and 2 different
platforms.
I'm not sure how much more I can do to convince you that I'm not making
this up.
I have tried the exact same parameters from tidy python bindings. I do
not see the same error. The error only seems to occur when I use php
bindings.
If you are going to close this bug, please don't close as bogus. This
bug is real.
Previous Comments:
[2006-11-23 21:11:31] [EMAIL PROTECTED]
Works just fine here using both libtidy-CVS and default SuSE version
(built on Mar 19 2005).
Please update libtidy to the latest CVS, and if that doesn't help, harp
on this to libtidy developers.
# ./sapi/cli/php /tmp/2.php
# cat /tmp/2.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[2006-11-23 20:59:58] konstantin dot ryabitsev at mcgill dot ca
[EMAIL PROTECTED]:[~]$ rpm -q libtidy
libtidy-0:0.99.0-11.20051025.fc6.i386
(this is the latest released -- I have previously built the latest CVS
of libtidy while testing this bug, but there was no difference in the
end-result)
[2006-11-23 20:56:35] [EMAIL PROTECTED]
Which Tidy version are you using?
[2006-11-23 20:51:44] konstantin dot ryabitsev at mcgill dot ca
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
[2006-11-23 18:57:01] [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
Cannot reproduce.
I get the very expected result.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Opn->Bgs]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
Updated by: [EMAIL PROTECTED]
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.2.0
New Comment:
Works just fine here using both libtidy-CVS and default SuSE version
(built on Mar 19 2005).
Please update libtidy to the latest CVS, and if that doesn't help, harp
on this to libtidy developers.
# ./sapi/cli/php /tmp/2.php
# cat /tmp/2.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
Previous Comments:
[2006-11-23 20:59:58] konstantin dot ryabitsev at mcgill dot ca
[EMAIL PROTECTED]:[~]$ rpm -q libtidy
libtidy-0:0.99.0-11.20051025.fc6.i386
(this is the latest released -- I have previously built the latest CVS
of libtidy while testing this bug, but there was no difference in the
end-result)
[2006-11-23 20:56:35] [EMAIL PROTECTED]
Which Tidy version are you using?
[2006-11-23 20:51:44] konstantin dot ryabitsev at mcgill dot ca
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
[2006-11-23 18:57:01] [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
Cannot reproduce.
I get the very expected result.
[2006-11-23 18:04:49] konstantin dot ryabitsev at mcgill dot ca
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
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/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Fbk->Opn]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
User updated by: konstantin dot ryabitsev at mcgill dot ca
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.2.0
New Comment:
[EMAIL PROTECTED]:[~]$ rpm -q libtidy
libtidy-0:0.99.0-11.20051025.fc6.i386
(this is the latest released -- I have previously built the latest CVS
of libtidy while testing this bug, but there was no difference in the
end-result)
Previous Comments:
[2006-11-23 20:56:35] [EMAIL PROTECTED]
Which Tidy version are you using?
[2006-11-23 20:51:44] konstantin dot ryabitsev at mcgill dot ca
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
[2006-11-23 18:57:01] [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
Cannot reproduce.
I get the very expected result.
[2006-11-23 18:04:49] konstantin dot ryabitsev at mcgill dot ca
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
[2006-11-08 14:40:50] konstantin dot ryabitsev at mcgill dot ca
I disagree. The bug does not occur when running tidy with the same
parameters, only when invoked as part of a PHP script. I will ask on
the libtidy support list, but I believe their answer will be to file a
bug with php.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Opn->Fbk]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
Updated by: [EMAIL PROTECTED]
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.2.0
New Comment:
Which Tidy version are you using?
Previous Comments:
[2006-11-23 20:51:44] konstantin dot ryabitsev at mcgill dot ca
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
[2006-11-23 18:57:01] [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
Cannot reproduce.
I get the very expected result.
[2006-11-23 18:04:49] konstantin dot ryabitsev at mcgill dot ca
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
[2006-11-08 14:40:50] konstantin dot ryabitsev at mcgill dot ca
I disagree. The bug does not occur when running tidy with the same
parameters, only when invoked as part of a PHP script. I will ask on
the libtidy support list, but I believe their answer will be to file a
bug with php.
[2006-11-08 03:07:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is a libtidy bug.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Fbk->Opn]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
User updated by: konstantin dot ryabitsev at mcgill dot ca
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.2.0
New Comment:
No, same results with the latest CVS snapshot. I have now been able to
reproduce this problem on the followin systems:
* Fedora Core 5
* Fedora Core 6
* RHEL 4
* Debian Unstable
It's not a corner case.
---
[EMAIL PROTECTED]:[~]$ cat tidy.php
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:value,wps:var'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
[EMAIL PROTECTED]:[~]$ php -version
PHP 5.2.1-dev (cli) (built: Nov 23 2006 15:32:59)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
[EMAIL PROTECTED]:[~]$ php tidy.php
Previous Comments:
[2006-11-23 18:57:01] [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
Cannot reproduce.
I get the very expected result.
[2006-11-23 18:04:49] konstantin dot ryabitsev at mcgill dot ca
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
[2006-11-08 14:40:50] konstantin dot ryabitsev at mcgill dot ca
I disagree. The bug does not occur when running tidy with the same
parameters, only when invoked as part of a PHP script. I will ask on
the libtidy support list, but I believe their answer will be to file a
bug with php.
[2006-11-08 03:07:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is a libtidy bug.
[2006-11-07 22:22:59] konstantin dot ryabitsev at mcgill dot ca
Specifying "Tidy:" in the Summary.
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/39417
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Opn->Fbk]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
Updated by: [EMAIL PROTECTED]
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.2.0
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
Cannot reproduce.
I get the very expected result.
Previous Comments:
[2006-11-23 18:04:49] konstantin dot ryabitsev at mcgill dot ca
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
[2006-11-08 14:40:50] konstantin dot ryabitsev at mcgill dot ca
I disagree. The bug does not occur when running tidy with the same
parameters, only when invoked as part of a PHP script. I will ask on
the libtidy support list, but I believe their answer will be to file a
bug with php.
[2006-11-08 03:07:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is a libtidy bug.
[2006-11-07 22:22:59] konstantin dot ryabitsev at mcgill dot ca
Specifying "Tidy:" in the Summary.
[2006-11-07 22:19:03] konstantin dot ryabitsev at mcgill dot ca
Description:
I seem to get odd behaviour running the following code. Theoretically
(and confirmed by running command-line tidy utility), the output should
contain all namespace-prepended tags. On my machine, the output only
contains the element, and none of the elements contained
within.
It's really weird. If I change the names to "wps:blo", "wps:var" and
"wps:val", it works. I'm really confused at this point.
Reproduce code:
---
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:var,wps:value'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39417 [Bgs->Opn]: Tidy: Handling of 'new-blocklevel-tags' inconsistent
ID: 39417
User updated by: konstantin dot ryabitsev at mcgill dot ca
Reported By: konstantin dot ryabitsev at mcgill dot ca
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
-PHP Version: 5.1.6
+PHP Version: 5.2.0
New Comment:
Upstream Tidy developers have ruled that this bug is not a bug in
libtidy, but a bug in php bindings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1598422&group_id=27659&atid=390963
Please do not close as "bogus" -- this is a PHP bug that needs to be
fixed.
Previous Comments:
[2006-11-08 14:40:50] konstantin dot ryabitsev at mcgill dot ca
I disagree. The bug does not occur when running tidy with the same
parameters, only when invoked as part of a PHP script. I will ask on
the libtidy support list, but I believe their answer will be to file a
bug with php.
[2006-11-08 03:07:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is a libtidy bug.
[2006-11-07 22:22:59] konstantin dot ryabitsev at mcgill dot ca
Specifying "Tidy:" in the Summary.
[2006-11-07 22:19:03] konstantin dot ryabitsev at mcgill dot ca
Description:
I seem to get odd behaviour running the following code. Theoretically
(and confirmed by running command-line tidy utility), the output should
contain all namespace-prepended tags. On my machine, the output only
contains the element, and none of the elements contained
within.
It's really weird. If I change the names to "wps:blo", "wps:var" and
"wps:val", it works. I'm really confused at this point.
Reproduce code:
---
';
$config = array(
'new-blocklevel-tags' => 'wps:block,wps:var,wps:value'
);
$tidy = tidy_parse_string($contents, $config, 'utf8');
$tidy->cleanRepair();
print "{$tidy->value}\n";
?>
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=39417&edit=1
#39609 [Opn]: increment/decrement inconsistency
ID: 39609 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Feature/Change Request PHP Version: 5.2.0 New Comment: Reclassified as feature request. Previous Comments: [2006-11-23 16:31:22] [EMAIL PROTECTED] Description: Using the increment or decrement operators immediately following respectively a plus or minus with a non-variable expression produces a parse error. Reproduce code: --- ($a+++$b) // works (1+$a++) // works (1-++$a) // works ($a+++1) // works (1+++$a) // parse error ($a---$b) // works (1-$a--) // works (1+--$a) // works ($a---1) // works (1---$a) // parse error -- Edit this bug report at http://bugs.php.net/?id=39609&edit=1
#39609 [NEW]: increment/decrement inconsistency
From: [EMAIL PROTECTED] Operating system: PHP version: 5.2.0 PHP Bug Type: Scripting Engine problem Bug description: increment/decrement inconsistency Description: Using the increment or decrement operators immediately following respectively a plus or minus with a non-variable expression produces a parse error. Reproduce code: --- ($a+++$b) // works (1+$a++) // works (1-++$a) // works ($a+++1) // works (1+++$a) // parse error ($a---$b) // works (1-$a--) // works (1+--$a) // works ($a---1) // works (1---$a) // parse error -- Edit bug report at http://bugs.php.net/?id=39609&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39609&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39609&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39609&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39609&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39609&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39609&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39609&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39609&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39609&r=support Expected behavior:http://bugs.php.net/fix.php?id=39609&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39609&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39609&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39609&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39609&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39609&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39609&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39609&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39609&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39609&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39609&r=mysqlcfg
#38915 [Com]: mod_php: system() (and similar) don't cleanup opened handles of Apache
ID: 38915
Comment by: php at vanviegen dot net
Reported By: dimmoborgir at gmail dot com
Status: Open
Bug Type: Apache2 related
Operating System: UNIX
PHP Version: 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5
New Comment:
It seems that the mail() function is suffering from the
same problem. It is rather scary to see Apache failing to
restart, because the MTA (exim in our case) is already
listening on port *:80 !
More details:
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030407/msg00049.html
Previous Comments:
[2006-10-30 16:55:36] jlawson-php at bovine dot net
It should be PHP's responsibility to close all open file handles (after
forking but before the exec).
Keep in mind that PHP is running as a module within the same process
space as Apache, and those private FDs are required for it to operate.
Apache cannot reasonably close and re-open all of those whenever it is
invoking a module's handlers, nor can it reasonably run modules in a
separate process. Modules are intended to be trusted code and so
Apache does not attempt to protect itself from misdesigned modules.
(In the case where PHP is installed as a CGI and not a module, then
Apache does indeed close the private FDs prior to running PHP.)
For example, when a CGI process via Apache's "mod_cgi", that module is
responsible for ensuring that it explicitly closes all open files prior
to the exec(). PHP is in a similar situation and should also do the
same when executing sub-processes.
Passing blame to Apache by saying that they should use "close on fork"
fcntl is not reasonable. Its current expectation is that modules which
need to fork will explicitly close files (as demonstrated by mod_cgi's
own implementation).
[2006-10-22 19:13:26] dimmoborgir at gmail dot com
There are some people that disagree.
Let them express their opinion here.
[2006-10-20 09:48:43] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The opened file descriptors are opened by Apache.
It is the job of Apache to protect them, not something that should be
reinvented in all apache modules.
Not a bug in PHP.
[2006-09-24 18:17:22] dimmoborgir at gmail dot com
Tested on versions 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5.
[2006-09-21 19:15:25] dimmoborgir at gmail dot com
Description:
The problem is in exec, system, popen (and similar) PHP functions. The
fact is that PHP doesn't sanitize opened file descriptors before
executing a program.
These functions use popen() C function to spawn a program.
popen() is equal to the successive execution of
pipe(), fork(), dup2(), exec().
These functions keep all opened handles. (Except STDOUT, which is
replaced to pipe).
This bug makes php-includes vulnerabilities more dangerous.
If the server uses mod_php, and we can execute shell commands via
system(), then we can, e.g. stop apache processes (by sending a
SIGSTOP), and to listen and process connections on 80 port (opened by
Apache, and transmitted to us by PHP). Also we can write anything to
its errorlog.
Reproduce code:
---
Some steps to reproduce a bug.
First. Simple program to wait :)
# cat test1.c
int main()
{
setsid( );
sleep( 1 );
}
#gcc -o test1 test1.c
Ok. Let's make a php script:
#cat a.php
Request: http://127.0.0.1/a.php
Good. Now see opened handles:
#lsof | grep test1
test1 cwdDIR /usr/local/apache2/htdocs
test1 rtdDIR /
test1 txtREG /var/www/html/test1
test1 memREG /lib/tls/libc-2.3.5.so
test1 memREG /lib/ld-2.3.5.so
test1 memREG [stack] (stat: No such file or
directory)
test1 0r CHR /dev/null
test1 1w FIFO pipe
test1 2w REG /usr/local/apache2/logs/error_log
test1 3u IPv4 *:http (LISTEN)
test1 4r FIFO pipe
test1 5w FIFO pipe
test1 6w REG /usr/local/apache2/logs/error_log
test1 7w REG /usr/local/apache2/logs/access_log
test1 8r unknown inode type
test1 9u IPv4 10.0.0.2:http->10.0.0.1:2134
(CLOSE_WAIT)
So, our
#39583 [Fbk->Opn]: FTP function always transfers in binary mode
ID: 39583
User updated by: ts dot serveroperations at wmdata dot com
Reported By: ts dot serveroperations at wmdata dot com
-Status: Feedback
+Status: Open
Bug Type: FTP related
Operating System: Redhat Enterprise ES version 4
PHP Version: 4.4.4
New Comment:
Is this what you wanted? I just breaked at the breakpoints, didn't do
any steps. I did this in command-line php. I recompiled PHP (CVS
version) with the following configure:
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
--enable-module=so --enable-ftp --enable-debug
If you want I can redo it with php 4.4.4.
# gdb /usr/local/bin/php
GNU gdb Red Hat Linux (6.1post-1.20040607.62rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break ftp_put
Breakpoint 1 at 0x807bd51: file
/usr/local/src/php4-STABLE-200611211330/ext/ftp/ftp.c, line 759.
(gdb) break ftp_type
Breakpoint 2 at 0x807abc4: file
/usr/local/src/php4-STABLE-200611211330/ext/ftp/ftp.c, line 539.
(gdb) run /var/www/html/mupp/index.php
Starting program: /usr/local/bin/php /var/www/html/mupp/index.php
Connected to localhost, for user temp
Breakpoint 1, ftp_put (ftp=0x8628d1c, path=0x8628bfc
"/tempdir/testfile.txt", instream=0x8625f4c, type=FTPTYPE_ASCII,
startpos=140656052)
at /usr/local/src/php4-STABLE-200611211330/ext/ftp/ftp.c:759
759 {
(gdb) c
Continuing.
Breakpoint 2, ftp_type (ftp=0x0, type=140656052) at
/usr/local/src/php4-STABLE-200611211330/ext/ftp/ftp.c:539
539 {
(gdb) c
Continuing.
Uploaded /var/www/html/testfile.txt to localhost as
/tempdir/testfile.txt
Program exited normally.
(gdb)
Previous Comments:
[2006-11-22 15:50:36] [EMAIL PROTECTED]
That's right, the default mode is binary, but I don't see any TYPE
commands in your log.
The ftp_put() function first sends "TYPE " command and STOR after
that.
Can you trace it in gdb and set a breakpoint on "ftp_put" and
"ftp_type" functions to see how exactly they are executed?
[2006-11-22 15:18:25] ts dot serveroperations at wmdata dot com
This is the transferlog from the ftpserver:
Wed Nov 22 15:08:25 2006 0 drops 83 /site/tempdir/testfile.txt b _ i r
temp ftp 0 *
The ftp server is glftpd 2.01 for i386 Linux
We sniffed the transfer using tcpdump, here's the output, sorry that it
is in HEX but we cut off all numbers to reduce linesize, but it is still
readable and you can make out 150.Opening.BINARY.mode:
547369717(0) win 32767
..E.
.<[EMAIL PROTECTED]@.p...
...p
[EMAIL PROTECTED]
[-
536371407(0) ack 3547369718 win 32767
..E.
.<[EMAIL PROTECTED]@.<...
...p
[EMAIL PROTECTED]
[-.}[-
92
..E.
[EMAIL PROTECTED]@.p...
...p
...}[-.}
[-
3538374111(0) win 32767
..E.
.<[EMAIL PROTECTED]@.%...
.q..M...
[EMAIL PROTECTED]
[d
3538374112 win 0
..E.
.([EMAIL PROTECTED]@.0...
...qM.P.
..
1 win 8192
..E.
[EMAIL PROTECTED]@.V|..
...p
...`...}[i.}
[-220.localhost.
Dropsite..(glFTP
192
..E.
[EMAIL PROTECTED]@.p...
...p
...}[i.}
[i
57 win 8192
..E.
[EMAIL PROTECTED]@.p...
...p
...3...}[j.}
[iUSER.temp..
192
..E.
[EMAIL PROTECTED]@.V...
...p
...}[j.}
[j
k 12 win 8192
..E.
[EMAIL PROTECTED]@.V...
...p
...I...}[p.}
[j331.Password.r
equired.for.temp
k 90 win 8192
..E.
[EMAIL PROTECTED]@.p...
...p.)..
...3...}[p.}
[pPASS.temp..
ack 23 win 8192
..E.
[EMAIL PROTECTED]@.T...
.).p
...}[x.}
[p230-..
8192
..E.
[EMAIL PROTECTED]@.p...
...p
...}[..}
[x
ack 23 win 8192
..E.
[EMAIL PROTECTED]@.U...
...p
...}[..}
[.230-.`-=--
8192
..E.
[EMAIL PROTECTED]@.p...
...p
...}[..}
[.
k 711 win 8192
..E.
[EMAIL PROTECTED]@.p...
...p
[EMAIL PROTECTED]
[.PORT.127,0,0,1
,138,186..
ack 47 win 8192
..E.
[EMAIL PROTECTED]@.V...
...p.$..
...F...}[..}
[.200.PORT.comma
nd.successful...
k 741 win 8192
..E.
[EMAIL PROTECTED]@.p...
...p.$..
...D...}[..}
[.STOR./tempdir/
testfile.txt..
:3545163343(0) win 32767
.
#39606 [Opn->Asn]: Use of com.typelib_file in PHP.ini STILL causes A/V
ID: 39606 Updated by: [EMAIL PROTECTED] Reported By: willw at applied dot co dot uk -Status: Open +Status: Assigned Bug Type: COM related Operating System: Windows XP SP2 PHP Version: 5CVS-2006-11-23 (snap) -Assigned To: +Assigned To: wez Previous Comments: [2006-11-23 13:15:48] willw at applied dot co dot uk Description: Use of the com.typelib_file to set a text file containing a list of typelibs causes PHP to crash with an A/V at startup. This is a sequel to Bug #38400 which was raised 09/08/2006 and closed 18/10/2006 with report 'fixed in CVS'. Although very similar, it is a different bug. Reproduce code: --- Alter a working PHP.ini so that it sets com.typelib_file to point to a text file. To see the bug, the named file must exist, and contain at least one entry, and the entry *must* be a valid type library. (If it points to, eg, a text file, then the bug doesn't show.) My example uses a Windows type library I found in the Windows directory activeds.tlb. I chose this so that there is no need for the tester/fixer to search out a COM component, and so that suspicion didn't fall on my type library. (The tester may wish to check that his choice of test type library loads without problem in PHP 4; this one does.) PHP.ini: ... [COM] com.typelib_file = "C:/PHP/typelib_files.txt" ... contents of typelib_files.txt: C:\WinNt\System32\activeds.tlb Expected result: I had hoped for no crash :-( Actual result: -- Here is a backtrace made with php5.2-win32-200611221530.zip 5d8b53ec() php5ts.dll!php_com_load_typelib_via_cache(char * search_string=0x0086761c, int codepage=0, int * cached=0x0140fd3c, void * * * tsrm_ls=0x012412f0) Line 242 C php5ts.dll!OnTypeLibFileUpdate(_zend_ini_entry * entry=0x0129d830, char * new_value=0x0003, unsigned int new_value_length=54, void * mh_arg1=0x, void * mh_arg2=0x, void * mh_arg3=0x, int stage=1, void * * * tsrm_ls=0x012412f0) Line 155 + 0x1f bytesC php5ts.dll!zend_ini_refresh_cache(_zend_ini_entry * p=0x0129d830, int stage=1, void * * * tsrm_ls=0x012412f0) Line 220 + 0x21 bytes C php5ts.dll!zend_hash_apply_with_argument(_hashtable * ht=0x0129a5d0, int (void *, void *, void * * *)* apply_func=0x00af9560, void * argument=0x0001, void * * * tsrm_ls=0x012412f0) Line 692 + 0xa bytes C php5ts.dll!zend_ini_refresh_caches(int stage=1, void * * * tsrm_ls=0x012412f0) Line 227 + 0x26 bytes C php5ts.dll!zend_new_thread_end_handler(unsigned long thread_id=3676, void * * * tsrm_ls=0x012412f0) Line 526 + 0x8 bytesC php5ts.dll!allocate_new_resource(_tsrm_tls_entry * * thread_resources_ptr=0x0082244c, unsigned long thread_id=3676) Line 300 + 0x6 bytes C php5ts.dll!ts_resource_ex(int id=0, unsigned long * th_id=0x0e5c) Line 362C php5apache.dll!send_php(request_rec * r=0x00a07040, int display_source_mode=0, char * filename=0x) Line 583C php5apache.dll!send_parsed_php(request_rec * r=0x00a07040) Line 677 + 0xe bytes C ApacheCore.dll!6ff64bc7() [Frames below may be incorrect and/or missing, no symbols loaded for ApacheCore.dll] ApacheCore.dll!6ff74a73() ApacheCore.dll!6ff74746() ApacheCore.dll!6ff6be0f() [EMAIL PROTECTED]() + 0xc6 bytes [EMAIL PROTECTED]() + 0x40 bytes This snapshot version differed from PHP5.2 in that it did not die until I tried to run some code (PHP5.2 dies at startup, preventing Apache from starting. The snapshot only kills one thread.) So I suspect some lazy initialisation has been introduced since PHP5.2 was released. But I am confident it is the same bug between 5.2 and the snapshot. The com.typelib_file directive has not worked since V5.0 of PHP was released. Please, may I politely ask if there is any chance of whoever makes any further fix testing that it with some imported constants in PHP code before rereleasing? -- Edit this bug report at http://bugs.php.net/?id=39606&edit=1
#39606 [NEW]: Use of com.typelib_file in PHP.ini STILL causes A/V
From: willw at applied dot co dot uk Operating system: Windows XP SP2 PHP version: 5CVS-2006-11-23 (snap) PHP Bug Type: COM related Bug description: Use of com.typelib_file in PHP.ini STILL causes A/V Description: Use of the com.typelib_file to set a text file containing a list of typelibs causes PHP to crash with an A/V at startup. This is a sequel to Bug #38400 which was raised 09/08/2006 and closed 18/10/2006 with report 'fixed in CVS'. Although very similar, it is a different bug. Reproduce code: --- Alter a working PHP.ini so that it sets com.typelib_file to point to a text file. To see the bug, the named file must exist, and contain at least one entry, and the entry *must* be a valid type library. (If it points to, eg, a text file, then the bug doesn't show.) My example uses a Windows type library I found in the Windows directory activeds.tlb. I chose this so that there is no need for the tester/fixer to search out a COM component, and so that suspicion didn't fall on my type library. (The tester may wish to check that his choice of test type library loads without problem in PHP 4; this one does.) PHP.ini: ... [COM] com.typelib_file = "C:/PHP/typelib_files.txt" ... contents of typelib_files.txt: C:\WinNt\System32\activeds.tlb Expected result: I had hoped for no crash :-( Actual result: -- Here is a backtrace made with php5.2-win32-200611221530.zip 5d8b53ec() php5ts.dll!php_com_load_typelib_via_cache(char * search_string=0x0086761c, int codepage=0, int * cached=0x0140fd3c, void * * * tsrm_ls=0x012412f0) Line 242C php5ts.dll!OnTypeLibFileUpdate(_zend_ini_entry * entry=0x0129d830, char * new_value=0x0003, unsigned int new_value_length=54, void * mh_arg1=0x, void * mh_arg2=0x, void * mh_arg3=0x, int stage=1, void * * * tsrm_ls=0x012412f0) Line 155 + 0x1f bytes C php5ts.dll!zend_ini_refresh_cache(_zend_ini_entry * p=0x0129d830, int stage=1, void * * * tsrm_ls=0x012412f0) Line 220 + 0x21 bytes C php5ts.dll!zend_hash_apply_with_argument(_hashtable * ht=0x0129a5d0, int (void *, void *, void * * *)* apply_func=0x00af9560, void * argument=0x0001, void * * * tsrm_ls=0x012412f0) Line 692 + 0xa bytes C php5ts.dll!zend_ini_refresh_caches(int stage=1, void * * * tsrm_ls=0x012412f0) Line 227 + 0x26 bytes C php5ts.dll!zend_new_thread_end_handler(unsigned long thread_id=3676, void * * * tsrm_ls=0x012412f0) Line 526 + 0x8 bytes C php5ts.dll!allocate_new_resource(_tsrm_tls_entry * * thread_resources_ptr=0x0082244c, unsigned long thread_id=3676) Line 300 + 0x6 bytes C php5ts.dll!ts_resource_ex(int id=0, unsigned long * th_id=0x0e5c) Line 362C php5apache.dll!send_php(request_rec * r=0x00a07040, int display_source_mode=0, char * filename=0x) Line 583C php5apache.dll!send_parsed_php(request_rec * r=0x00a07040) Line 677 + 0xe bytes C ApacheCore.dll!6ff64bc7() [Frames below may be incorrect and/or missing, no symbols loaded for ApacheCore.dll] ApacheCore.dll!6ff74a73() ApacheCore.dll!6ff74746() ApacheCore.dll!6ff6be0f() [EMAIL PROTECTED]() + 0xc6 bytes [EMAIL PROTECTED]() + 0x40 bytes This snapshot version differed from PHP5.2 in that it did not die until I tried to run some code (PHP5.2 dies at startup, preventing Apache from starting. The snapshot only kills one thread.) So I suspect some lazy initialisation has been introduced since PHP5.2 was released. But I am confident it is the same bug between 5.2 and the snapshot. The com.typelib_file directive has not worked since V5.0 of PHP was released. Please, may I politely ask if there is any chance of whoever makes any further fix testing that it with some imported constants in PHP code before rereleasing? -- Edit bug report at http://bugs.php.net/?id=39606&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39606&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39606&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39606&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39606&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39606&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39606&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39606&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39606&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39606&r=support Expected behavior:http://bugs.php.net/fix.php?id=39606&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39606&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39606&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39606&r=globals PHP 3 support discontinued: http://bug
#39605 [Opn->Bgs]: Function Error
ID: 39605 Updated by: [EMAIL PROTECTED] Reported By: steve at directprint dot com dot au -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: MacOS X Server 10.4.8 PHP Version: 5.2.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-11-23 13:07:01] steve at directprint dot com dot au Description: Aftrer upgrading to 5.2.0, I now get a blank page. Below is the from the web error log. Reproduce code: --- [Thu Nov 23 21:59:21 2006] [error] PHP Warning: require_once(./global.php) [function.require-once]: failed to open stream: No such file or directory in /Volumes/SOHOraid/forum/index.php on line 55 [Thu Nov 23 21:59:21 2006] [error] PHP Fatal error: require_once() [function.require]: Failed opening required './global.php' (include_path='.:/usr/local/php5/lib/php') in /Volumes/SOHOraid/forum/index.php on line 55 Expected result: Forum index Actual result: -- Blank Page -- Edit this bug report at http://bugs.php.net/?id=39605&edit=1
#39605 [NEW]: Function Error
From: steve at directprint dot com dot au Operating system: MacOS X Server 10.4.8 PHP version: 5.2.0 PHP Bug Type: Directory function related Bug description: Function Error Description: Aftrer upgrading to 5.2.0, I now get a blank page. Below is the from the web error log. Reproduce code: --- [Thu Nov 23 21:59:21 2006] [error] PHP Warning: require_once(./global.php) [function.require-once]: failed to open stream: No such file or directory in /Volumes/SOHOraid/forum/index.php on line 55 [Thu Nov 23 21:59:21 2006] [error] PHP Fatal error: require_once() [function.require]: Failed opening required './global.php' (include_path='.:/usr/local/php5/lib/php') in /Volumes/SOHOraid/forum/index.php on line 55 Expected result: Forum index Actual result: -- Blank Page -- Edit bug report at http://bugs.php.net/?id=39605&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39605&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39605&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39605&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39605&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39605&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39605&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39605&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39605&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39605&r=support Expected behavior:http://bugs.php.net/fix.php?id=39605&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39605&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39605&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39605&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39605&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39605&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39605&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39605&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39605&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39605&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39605&r=mysqlcfg
#38744 [Com]: PHP5TS.DLL causes w3svc crash and application pool termination
ID: 38744 Comment by: robcw at hotmail dot com Reported By: jneill at gamedaytv dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 2003 SP 1 PHP Version: 5.1.6 New Comment: Is this the same as bug report 37483? http://bugs.php.net/bug.php?id=37483 Previous Comments: [2006-10-31 10:41:32] ted at connectingsweden dot com Im getting this exact error also... i have disabled the application pool recycle functions in the IIS server it stil happens this emm problem but it takes a couple of days before it does simple idiot fix is to just goto the server and do a load on a php page for the application pool and then it works again for a couple of days. If i reactivate the recycle functions ill end up with counltess of php page downtime sessions where i have to go and reload a php page localy on the server to fix it.. i run 5.1.6 as php rel ver my question is... Is there a older versions of the php releases that do not cause this effect? untill there is a permanent fix for it. [2006-09-18 17:09:21] opa56 at myownnet dot ch Same error here: A process serving application pool 'mysite1' terminated unexpectedly. The process id was '2828'. The process exit code was '0xc005'. A process serving application pool 'mysite2' terminated unexpectedly. The process id was '3132'. The process exit code was '0xc005'. etc. The error occurs - each time, the w3svc is recycled because of idle-timeout (default 20 min.)or uptime 1740 min. - sinze version 5.1.4 of php If idle-timeout occurs, no script is running at this moment! Only the isapi is loaded. Same error, also if no php.ini exist, means no extensions are loaded [2006-09-15 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-09-14 14:27:41] helder at hightechvision dot com I'm getting precisely the same debug output from IIS Diagnostics Debug Diagnostics Tool running on a Windows Server 2003 SP1 with the build php5.2-win32-200609131430.zip If you want I can provide you crash dumps. [2006-09-07 20:50:59] [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 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/38744 -- Edit this bug report at http://bugs.php.net/?id=38744&edit=1
#39604 [WFx]: File Upload Original name problem if it is with apostrophe.
ID: 39604 Updated by: [EMAIL PROTECTED] Reported By: akocherhan at sagasoft dot com Status: Wont fix Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.4.4 New Comment: If you manage to find the patch for it (from either HEAD or PHP_5_2), we can have a look at it. Previous Comments: [2006-11-23 10:38:52] akocherhan at sagasoft dot com So as I understand it is not possible to fix this bug in php version 4. And we need to move to php version 5, recheck/retest/rewrite all php scripts? Maybe there is another way? Thanks for understanding. [2006-11-23 10:32:32] [EMAIL PROTECTED] I don't think so. PHP4 is in maintainance state and only critical/security problems are fixed there. This is neither critical nor security related. [2006-11-23 10:27:08] akocherhan at sagasoft dot com Thanks, but my web site use php version 4. Is this bug fixed for php version 4? [2006-11-23 10:23:00] [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-11-23 10:20:03] akocherhan at sagasoft dot com Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39604 [WFx]: File Upload Original name problem if it is with apostrophe.
ID: 39604 User updated by: akocherhan at sagasoft dot com Reported By: akocherhan at sagasoft dot com Status: Wont fix Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.4.4 New Comment: So as I understand it is not possible to fix this bug in php version 4. And we need to move to php version 5, recheck/retest/rewrite all php scripts? Maybe there is another way? Thanks for understanding. Previous Comments: [2006-11-23 10:32:32] [EMAIL PROTECTED] I don't think so. PHP4 is in maintainance state and only critical/security problems are fixed there. This is neither critical nor security related. [2006-11-23 10:27:08] akocherhan at sagasoft dot com Thanks, but my web site use php version 4. Is this bug fixed for php version 4? [2006-11-23 10:23:00] [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-11-23 10:20:03] akocherhan at sagasoft dot com Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39604 [Opn->WFx]: File Upload Original name problem if it is with apostrophe.
ID: 39604 Updated by: [EMAIL PROTECTED] Reported By: akocherhan at sagasoft dot com -Status: Open +Status: Wont fix Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.4.4 New Comment: I don't think so. PHP4 is in maintainance state and only critical/security problems are fixed there. This is neither critical nor security related. Previous Comments: [2006-11-23 10:27:08] akocherhan at sagasoft dot com Thanks, but my web site use php version 4. Is this bug fixed for php version 4? [2006-11-23 10:23:00] [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-11-23 10:20:03] akocherhan at sagasoft dot com Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39604 [Fbk->Opn]: File Upload Original name problem if it is with apostrophe.
ID: 39604 User updated by: akocherhan at sagasoft dot com Reported By: akocherhan at sagasoft dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 4.4.4 New Comment: Thanks, but my web site use php version 4. Is this bug fixed for php version 4? Previous Comments: [2006-11-23 10:23:00] [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-11-23 10:20:03] akocherhan at sagasoft dot com Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39604 [Opn->Fbk]: File Upload Original name problem if it is with apostrophe.
ID: 39604 Updated by: [EMAIL PROTECTED] Reported By: akocherhan at sagasoft dot com -Status: Open +Status: Feedback -Bug Type: Scripting Engine problem +Bug Type: Unknown/Other Function Operating System: Windows 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-11-23 10:20:03] akocherhan at sagasoft dot com Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit this bug report at http://bugs.php.net/?id=39604&edit=1
#39604 [NEW]: File Upload Original name problem if it is with apostrophe.
From: akocherhan at sagasoft dot com Operating system: Windows PHP version: 4.4.4 PHP Bug Type: Scripting Engine problem Bug description: File Upload Original name problem if it is with apostrophe. Description: I have the same problem as it was described in bug #31398 and #38245. I.e. if file name is test1'test2.txt the first part of the filename including the apostrophe is cut off so it shows as: test2.txt php version is 4.4.4. Also I tried to install the latest version from cvs (4.4.5 dev).But this bug still exist. Please tell me what I must to do to fix this problem. Reproduce code: --- File: Expected result: The full name of the file uploaded including the apostrophe. Actual result: -- The first part of the filename is cut off including the apostrophe. -- Edit bug report at http://bugs.php.net/?id=39604&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39604&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39604&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39604&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39604&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39604&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39604&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39604&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39604&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39604&r=support Expected behavior:http://bugs.php.net/fix.php?id=39604&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39604&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39604&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39604&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39604&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39604&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39604&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39604&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39604&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39604&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39604&r=mysqlcfg
#39601 [Opn->Fbk]: $GLOBALS superglobal and ${ {$ string variable parsing inconsistencies
ID: 39601
Updated by: [EMAIL PROTECTED]
Reported By: jkloske at itee dot uq dot edu dot au
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Centos
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-11-23 07:23:31] jkloske at itee dot uq dot edu dot au
Description:
The $GLOBALS superglobal when referenced inside a string using ${
(which is not strictly legal for PHP syntax, but which seems to work in
most other situations) doesn't appear to exist (it evaluates to an empty
string).
As soon as $GLOBALS is referenced anywhere else in that same scope via
either a direct expression or correctly inside a string using {$, even
if this occurs after the incorrect reference using ${ in a string, all
${ references work.
Very short example is included, to demonstrate, run as is, then run
with the commented out line uncommented.
I don't know that this is specifically a bug, but it does seem
inconsistent and potentially problematic, and at the very least should
be documented :)
I'm really sorry to report this with my version of PHP (4.3.11) but I
am not authorized to upgrade the version on the server, merely use it.
Reproduce code:
---
";
//$okayIwill = $GLOBALS['READMEIFYOUCAN'];
echo "${GLOBALS['READMEIFYOUCAN']}";
?>
Expected result:
A)
This line should appear twice!
This line should appear twice!
B)
Since this isn't strictly the correct format of {$, I would also accept
it printing out:
${GLOBALS['READMEIFYOUCAN']}
or perhaps some other strange PHP error type output or partially
printed versions of that string.
Actual result:
--
now uncomment the commented out line, and you see:
This line should appear twice!
This line should appear twice!
This seems to indicate that as long as $GLOBALS is referenced outside a
string, it works anywhere in the scope, even before it was first
referenced.
Note if you change either of the ${ inside the strings to {$ they both
work, regardless of the order.
--
Edit this bug report at http://bugs.php.net/?id=39601&edit=1
#39534 [Asn->Csd]: Error in maths to calculate of ZEND_MM_ALIGNED_MIN_HEADER_SIZE
ID: 39534 Updated by: [EMAIL PROTECTED] Reported By: wharmby at uk dot ibm dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5CVS-2006-11-16 (snap) Assigned To: dmitry New Comment: The patch committed into CVS HEAD and PHP_5_2. Thank you for catching the bug. Previous Comments: [2006-11-16 15:15:34] wharmby at uk dot ibm dot com Description: Error in maths spotted whilst reviewing the Memory Manager code in zend_alloc.c in order to get a general understanding of the allocation algorithm. I believe the maths involved in calculating the size of ZEND_MM_ALIGNED_MIN_HEADER_SIZE is incorrect as it stands although the problem reported only shows up in the DEBUG build currently. Enabling the debug printf at the start of zend_mm_startup_ex() helps to demonstrate the problem: Output with Retail build 0 : 16 1 1 1 : 16 1 1 2 : 16 1 1 3 : 16 1 1 4 : 16 1 1 5 : 16 1 1 6 : 16 1 1 7 : 16 1 1 8*: 16 1 1 9 : 24 1 2 10 : 24 1 2 11 : 24 1 2 . etc This shows that in the retail build we can see that a request for zero bytes requires a "true size" of 16 bytes and such blocks are added to/found in free_bucket[1]. Requests for 1-8 bytes also map to free_bucket[1], requests for 9-16 map to free_bucket[2] etc all as expected. However, in the DEBUG build we do not get the correct mapping between request size and free_bucket[]'s. Output from Debug build --- 0 : 48 1 2 1 : 48 1 2 2 : 48 1 2 3 : 48 1 2 4 : 48 1 2 5 : 56 1 3 6 : 56 1 3 7 : 56 1 3 8 : 56 1 3 9 : 56 1 3 10 : 56 1 3 11 : 56 1 3 12 : 56 1 3 .etc This shows that for a request size of zero bytes we require a "true size" of 48 bytes and such blocks are found in free_bucket[2], i.e free_bucket[1] is not used at all. Only a minor issue in the DEBUG version of the code I know but wrong all the same and in worse case it could mean that a problem that recreates with retail build is more difficult to recreate with debug build. The retail and debug algorithms should wherever possible cause the same results. The reason for this mis-mapping of blocks to free buckets is because ZEND_MM_ALIGNED_MIN_HEADER_SIZE currently equates to 40 rather than the correct value of 48 bytes. >From my reading of the code ZEND_MM_ALIGNED_MIN_HEADER_SIZE rather than the minimum size of a block header is more correctly the size of the smallest block which the Memory Manager will allocate and/or add to its free lists and is the greater of: (1) the size of a free block header itself, and (2) the size of block required in order to satisfy an allocate of the smallest permissible size which as the code stands is for zero bytes. In the retail build it will indeed be equal to the size of the larger of the zend_mm_block and zend_mm_free_block headers rounded to the next 8 byte multiple. However in the DEBUG build the magic slot which immediately follows the data portion of a block, i.e not part of header, needs to be correctly taken account of. The data portion of a block (even if its of zero length) must start on an 8 byte aligned boundary with the magic slot immediately after it. The code to calculate ZEND_MM_ALIGNED_MIN_HEADER_SIZE in zend_alloc.c is currently as follows: #define ZEND_MM_ALIGNED_MIN_HEADER_SIZE (sizeof(zend_mm_block)+END_MAGIC_SIZE>sizeof(zend_mm_free_block) ? ZEND_ALIGNED_SIZE(sizeof(zend_mm_block)+END_MAGIC_SIZE): ZEND_MM_ALIGNED_SIZE(sizeof(zend_mm_free_block))) So in the DEBUG build ZEND_MM_ALIGNED_MIN_HEADER_SIZE equates to 40 rather than the correct value of 48. The mistake is to add "sizeof(zend_mm_block)" and "END_MAGIC_SIZE" together before aligning. The code should read something more like: #define ZEND_MM_MIN_ALLOC_BLOCK_SIZE ZEND_MM_ALIGNED_SIZE(ZEND_MM_ALIGNED_HEADER_SIZE + END_MAGIC_SIZE) #define ZEND_MM_ALIGNED_MIN_HEADER_SIZE (ZEND_MM_MIN_ALLOC_BLOCK_SIZE > ZEND_MM_ALIGNED_FREE_HEADER_SIZE ? ZEND_MM_MIN_ALLOC_BLOCK_SIZE : ZEND_MM_ALIGNED_FREE_HEADER_SIZE) Which results in correct value for ZEND_MM_ALIGNED_MIN_HEADER_SIZE of 48. The incorrect value for ZEND_MM_ALIGNED_MIN_HEADER_SIZE has 2 additional side affects: (1) As ZEND_MM_ALIGNED_MIN_HEADER_SIZE is incorrectly calculated in the DEBUG build as 40 bytes any "remainder" of 40 bytes when allocating a block will get added to cache/free_bucket[1] but will never be used as its too small a block to satisfy any allocation request given that the minimum value for "true size" in the DEBUG build is 48 bytes. (2) ZEND_MM_MIN_SIZE currently equates to -4 in the DEBUG build which is a little strange although does not appear to cause any problems give
#39515 [Asn->Bgs]: SOAP fault detail does not contain attributes
ID: 39515
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
-Status: Assigned
+Status: Bogus
Bug Type: SOAP related
Operating System: SuSE Linux 9.3
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
The wsdl file doesn't describe fault massage at all.
ext/soap can handle only known attributes of known types, but wsdl says
nothing about
Previous Comments:
[2006-11-15 20:10:43] david at acz dot org
The service requires authentication, so unfortunately I cannot provide
a complete example, but this is the WSDL and how I am using it:
https://client.enhance.com/plm/services/CampaignWebService?wsdl
$client = new SoapClient($wsdl, array("exceptions" => 0));
$x = (DETAILS ELIDED)
$r = $client->addKeywords($x);
if (is_soap_fault($r))
{
// $r->detail is missing attributes
}
[2006-11-15 17:09:20] [EMAIL PROTECTED]
XML attributes are handled only if they are properly described in WSDL
file. Do you use any WSDL file? Can you post WSDL file and PHP code?
[2006-11-14 21:25:25] david at acz dot org
Description:
Attributes from tags inside a SOAP fault detail are not returned in the
SoapFault object. Below is a SOAP fault XML response and associated
SoapFault object. Notice that the attributes for the "keyword" tag are
missing.
Reproduce code:
---
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
ns1:badKeywords
error string here
http://xml.apache.org/axis/";>test.example.com
Expected result:
SoapFault Object
(
[message:protected] => error string here
[string:private] =>
[code:protected] => 0
[file:protected] => hello.php
[line:protected] => 166
[trace:private] => Array (ELIDED)
[faultstring] => error string here
[faultcode] => ns1:badKeywords
[detail] => stdClass Object
(
[hostname] => test.example.com
[keyword] => (ATTRIBUTES "reason" AND "value")
)
)
Actual result:
--
SoapFault Object
(
[message:protected] => error string here
[string:private] =>
[code:protected] => 0
[file:protected] => hello.php
[line:protected] => 166
[trace:private] => Array (ELIDED)
[faultstring] => error string here
[faultcode] => ns1:badKeywords
[detail] => stdClass Object
(
[hostname] => test.example.com
[keyword] =>
)
)
--
Edit this bug report at http://bugs.php.net/?id=39515&edit=1
#39603 [Opn->Fbk]: Apache crashed
ID: 39603 Updated by: [EMAIL PROTECTED] Reported By: hoangkent at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows server 2003 SP1 PHP Version: 5.2.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2006-11-23 08:50:15] hoangkent at gmail dot com Disable some ext can fix this problem Detail here: http://www.apachelounge.com/forum/viewtopic.php?p=4785 [2006-11-23 08:18:37] hoangkent at gmail dot com Description: The Apache2.2 service terminated unexpectedly. Event logs: Faulting application httpd.exe, version 2.2.3.0, faulting module unknown, version 0.0.0.0, fault address 0x01df2dc0. Expected result: php module has a bug ? -- Edit this bug report at http://bugs.php.net/?id=39603&edit=1
#39600 [Opn->Bgs]: it is giveing a notice that is "undefined index name" while we getting the file
ID: 39600 Updated by: [EMAIL PROTECTED] Reported By: yugandhar dot choragudi at gamil dot com -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: windows 2000 PHP Version: 4.4.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2006-11-23 05:36:38] yugandhar dot choragudi at gamil dot com Description: it is giveing a notice that is "undefined index name" while we getting the file USING $HTTP_POST_FILES[][]; Reproduce code: --- it is giveing a notice that is "undefined index name" while we getting the file USING $HTTP_POST_FILES[][]; -- Edit this bug report at http://bugs.php.net/?id=39600&edit=1
#39603 [Opn]: Apache crashed
ID: 39603 User updated by: hoangkent at gmail dot com Reported By: hoangkent at gmail dot com Status: Open Bug Type: Apache2 related Operating System: Windows server 2003 SP1 PHP Version: 5.2.0 New Comment: Disable some ext can fix this problem Detail here: http://www.apachelounge.com/forum/viewtopic.php?p=4785 Previous Comments: [2006-11-23 08:18:37] hoangkent at gmail dot com Description: The Apache2.2 service terminated unexpectedly. Event logs: Faulting application httpd.exe, version 2.2.3.0, faulting module unknown, version 0.0.0.0, fault address 0x01df2dc0. Expected result: php module has a bug ? -- Edit this bug report at http://bugs.php.net/?id=39603&edit=1
#39548 [Asn->Csd]: ZMSG_LOG_SCRIPT_NAME not routed to OutputDebugString() on Windows
ID: 39548 Updated by: [EMAIL PROTECTED] Reported By: wharmby at uk dot ibm dot com -Status: Assigned +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5CVS-2006-11-17 (snap) Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_2. Previous Comments: [2006-11-17 16:00:58] wharmby at uk dot ibm dot com Description: I have been playing around with the Zend Memory Manager leak detection code and have found that when I cause a memory leak the messages produced by the leak detection code go to 2 different destinations: (1) A single line message detailing the script name which caused the leak is sent to stderr although the message itself gives no indication of why its being produced, but (2) The details of the leak (address, filename, line number etc) go to OutputDebugString() I am running DebugView from : (www.microsoft.com/technet/sysinternals/utilities/debugview.mspx) to capture the messages and I see messages like: [Fri Nov 17 15:32:28 2006] Script: 'helloWorld.php' at stderr but the detail about the leak, e.g [3096] c:\phpdev\php5.2-200611171130\zend\zend_vm_execute.h(52) : Freeing 0x01101B68 (0 bytes), script=helloWorld.php is in my DebugView log. The stderr message on its own is of very little use unless it can be paired with the corresponding detail message. As the 2 messages go to different destinations this has to be done by comparing time stamps; possible but less than ideal. I can think of no good reason why the "script name" message is sent to stderr rather than DebugOutputString() so I assume this is just an oversight. Easy to fix my modifying the php_message_handler_for_zend() code to correctly route the ZMSG_LOG_SCRIPT_NAME message to OutputDebugString() on Windows. A patch to implement my suggested fix is here: http://pastebin.ca/250948 Reproduce code: --- To cause the memory leak in the first place I just hacked the code in zend_alloc.c method _zend_mm_free_int() such that it returns immediately without freeing anything. Then running a simple "HelloWorld" script using CLI produces many leak messages. Expected result: No messages to stderr and all leak messages in DebugView log Actual result: -- Majority of output in DebugView log but multiple instances of just the ZMSG_LOG_SCRIPT_NAME message at stderr, e.g C:\Eclipse-PHP\workspace\Testcases>php -f helloWorld.php [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' [Fri Nov 17 15:36:21 2006] Script: 'helloWorld.php' etc -- Edit this bug report at http://bugs.php.net/?id=39548&edit=1
#39603 [NEW]: Apache crashed
From: hoangkent at gmail dot com Operating system: Windows server 2003 SP1 PHP version: 5.2.0 PHP Bug Type: Apache2 related Bug description: Apache crashed Description: The Apache2.2 service terminated unexpectedly. Event logs: Faulting application httpd.exe, version 2.2.3.0, faulting module unknown, version 0.0.0.0, fault address 0x01df2dc0. Expected result: php module has a bug ? -- Edit bug report at http://bugs.php.net/?id=39603&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39603&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39603&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39603&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39603&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39603&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39603&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39603&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39603&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39603&r=support Expected behavior:http://bugs.php.net/fix.php?id=39603&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39603&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39603&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39603&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39603&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39603&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39603&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39603&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39603&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39603&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39603&r=mysqlcfg
#39602 [Asn->Csd]: Invalid session.save_handler crashes PHP
ID: 39602
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5CVS-2006-11-23 (CVS)
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_2.
Previous Comments:
[2006-11-23 08:01:34] [EMAIL PROTECTED]
Description:
PHP may crash if php.ini contains invalid setting for
"session.save_handler" directive.
Reproduce code:
---
Expected result:
no crach
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x0832cd57 in zend_objects_store_mark_destructed (objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
70 if (objects->object_buckets[i].valid) {
(gdb) p objects->object_buckets
$2 = (zend_object_store_bucket *) 0x0
(gdb) bt
#0 0x0832cd57 in zend_objects_store_mark_destructed
(objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
#1 0x082b9af7 in php_error_cb (type=1, error_filename=0x8434bcb
"Unknown",
error_lineno=0, format=0x8419663 "%s", args=0xbf801c58 "ÝÅ\224\b")
at /home/dmitry/php/php5.2/main/main.c:838
#2 0x0012c265 in soap_error_handler (error_num=1,
error_filename=0x8434bcb "Unknown", error_lineno=0,
format=0x8419663 "%s",
args=0xbf801c58 "ÝÅ\224\b") at
/home/dmitry/php/php5.2/ext/soap/soap.c:2022
#3 0x0830bac3 in zend_error (type=1, format=0x8419663 "%s")
at /home/dmitry/php/php5.2/Zend/zend.c:946
#4 0x082b921f in php_verror (docref=0x0, params=0x84190b1 "", type=1,
format=0x83f45eb "Cannot find save handler %s",
args=0xbf801d3c "@\226\206\b(Ë\224\b\224>\224\bh\035\200©SÇ.\b")
at /home/dmitry/php/php5.2/main/main.c:584
#5 0x082b9289 in php_error_docref0 (docref=0x0, type=1,
format=0x83f45eb "Cannot find save handler %s")
at /home/dmitry/php/php5.2/main/main.c:596
#6 0x0819d614 in OnUpdateSaveHandler (entry=0x88c6c10,
new_value=0x8869640 "qwerty", new_value_length=6, mh_arg1=0x0,
mh_arg2=0x0, mh_arg3=0x0, stage=8)
at /home/dmitry/php/php5.2/ext/session/session.c:107
#7 0x08320e95 in zend_restore_ini_entry_cb (ini_entry=0x88c6c10,
stage=8)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:55
#8 0x08320f2c in zend_restore_ini_entry_wrapper (ini_entry=0x894eb88)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:70
#9 0x08317f53 in zend_hash_apply (ht=0x894e458,
apply_func=0x8320f11 )
at /home/dmitry/php/php5.2/Zend/zend_hash.c:668
#10 0x08321031 in zend_ini_deactivate ()
at /home/dmitry/php/php5.2/Zend/zend_ini.c:109
#11 0x0830b8b7 in zend_deactivate () at
/home/dmitry/php/php5.2/Zend/zend.c:850
#12 0x082ba99a in php_request_shutdown (dummy=0x0)
at /home/dmitry/php/php5.2/main/main.c:1300
#13 0x0838631e in main (argc=4, argv=0xbf804304)
at /home/dmitry/php/php5.2/sapi/cgi/cgi_main.c:1792
--
Edit this bug report at http://bugs.php.net/?id=39602&edit=1
#39602 [Opn->Asn]: Invalid session.save_handler crashes PHP
ID: 39602
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5CVS-2006-11-23 (CVS)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2006-11-23 08:01:34] [EMAIL PROTECTED]
Description:
PHP may crash if php.ini contains invalid setting for
"session.save_handler" directive.
Reproduce code:
---
Expected result:
no crach
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x0832cd57 in zend_objects_store_mark_destructed (objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
70 if (objects->object_buckets[i].valid) {
(gdb) p objects->object_buckets
$2 = (zend_object_store_bucket *) 0x0
(gdb) bt
#0 0x0832cd57 in zend_objects_store_mark_destructed
(objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
#1 0x082b9af7 in php_error_cb (type=1, error_filename=0x8434bcb
"Unknown",
error_lineno=0, format=0x8419663 "%s", args=0xbf801c58 "ÝÅ\224\b")
at /home/dmitry/php/php5.2/main/main.c:838
#2 0x0012c265 in soap_error_handler (error_num=1,
error_filename=0x8434bcb "Unknown", error_lineno=0,
format=0x8419663 "%s",
args=0xbf801c58 "ÝÅ\224\b") at
/home/dmitry/php/php5.2/ext/soap/soap.c:2022
#3 0x0830bac3 in zend_error (type=1, format=0x8419663 "%s")
at /home/dmitry/php/php5.2/Zend/zend.c:946
#4 0x082b921f in php_verror (docref=0x0, params=0x84190b1 "", type=1,
format=0x83f45eb "Cannot find save handler %s",
args=0xbf801d3c "@\226\206\b(Ë\224\b\224>\224\bh\035\200©SÇ.\b")
at /home/dmitry/php/php5.2/main/main.c:584
#5 0x082b9289 in php_error_docref0 (docref=0x0, type=1,
format=0x83f45eb "Cannot find save handler %s")
at /home/dmitry/php/php5.2/main/main.c:596
#6 0x0819d614 in OnUpdateSaveHandler (entry=0x88c6c10,
new_value=0x8869640 "qwerty", new_value_length=6, mh_arg1=0x0,
mh_arg2=0x0, mh_arg3=0x0, stage=8)
at /home/dmitry/php/php5.2/ext/session/session.c:107
#7 0x08320e95 in zend_restore_ini_entry_cb (ini_entry=0x88c6c10,
stage=8)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:55
#8 0x08320f2c in zend_restore_ini_entry_wrapper (ini_entry=0x894eb88)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:70
#9 0x08317f53 in zend_hash_apply (ht=0x894e458,
apply_func=0x8320f11 )
at /home/dmitry/php/php5.2/Zend/zend_hash.c:668
#10 0x08321031 in zend_ini_deactivate ()
at /home/dmitry/php/php5.2/Zend/zend_ini.c:109
#11 0x0830b8b7 in zend_deactivate () at
/home/dmitry/php/php5.2/Zend/zend.c:850
#12 0x082ba99a in php_request_shutdown (dummy=0x0)
at /home/dmitry/php/php5.2/main/main.c:1300
#13 0x0838631e in main (argc=4, argv=0xbf804304)
at /home/dmitry/php/php5.2/sapi/cgi/cgi_main.c:1792
--
Edit this bug report at http://bugs.php.net/?id=39602&edit=1
#39602 [NEW]: Invalid session.save_handler crashes PHP
From: [EMAIL PROTECTED]
Operating system: *
PHP version: 5CVS-2006-11-23 (CVS)
PHP Bug Type: Reproducible crash
Bug description: Invalid session.save_handler crashes PHP
Description:
PHP may crash if php.ini contains invalid setting for
"session.save_handler" directive.
Reproduce code:
---
Expected result:
no crach
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x0832cd57 in zend_objects_store_mark_destructed (objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
70 if (objects->object_buckets[i].valid) {
(gdb) p objects->object_buckets
$2 = (zend_object_store_bucket *) 0x0
(gdb) bt
#0 0x0832cd57 in zend_objects_store_mark_destructed (objects=0x84697b8)
at /home/dmitry/php/php5.2/Zend/zend_objects_API.c:70
#1 0x082b9af7 in php_error_cb (type=1, error_filename=0x8434bcb
"Unknown",
error_lineno=0, format=0x8419663 "%s", args=0xbf801c58 "ÝÅ\224\b")
at /home/dmitry/php/php5.2/main/main.c:838
#2 0x0012c265 in soap_error_handler (error_num=1,
error_filename=0x8434bcb "Unknown", error_lineno=0, format=0x8419663
"%s",
args=0xbf801c58 "ÝÅ\224\b") at
/home/dmitry/php/php5.2/ext/soap/soap.c:2022
#3 0x0830bac3 in zend_error (type=1, format=0x8419663 "%s")
at /home/dmitry/php/php5.2/Zend/zend.c:946
#4 0x082b921f in php_verror (docref=0x0, params=0x84190b1 "", type=1,
format=0x83f45eb "Cannot find save handler %s",
args=0xbf801d3c "@\226\206\b(Ë\224\b\224>\224\bh\035\200©SÇ.\b")
at /home/dmitry/php/php5.2/main/main.c:584
#5 0x082b9289 in php_error_docref0 (docref=0x0, type=1,
format=0x83f45eb "Cannot find save handler %s")
at /home/dmitry/php/php5.2/main/main.c:596
#6 0x0819d614 in OnUpdateSaveHandler (entry=0x88c6c10,
new_value=0x8869640 "qwerty", new_value_length=6, mh_arg1=0x0,
mh_arg2=0x0, mh_arg3=0x0, stage=8)
at /home/dmitry/php/php5.2/ext/session/session.c:107
#7 0x08320e95 in zend_restore_ini_entry_cb (ini_entry=0x88c6c10,
stage=8)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:55
#8 0x08320f2c in zend_restore_ini_entry_wrapper (ini_entry=0x894eb88)
at /home/dmitry/php/php5.2/Zend/zend_ini.c:70
#9 0x08317f53 in zend_hash_apply (ht=0x894e458,
apply_func=0x8320f11 )
at /home/dmitry/php/php5.2/Zend/zend_hash.c:668
#10 0x08321031 in zend_ini_deactivate ()
at /home/dmitry/php/php5.2/Zend/zend_ini.c:109
#11 0x0830b8b7 in zend_deactivate () at
/home/dmitry/php/php5.2/Zend/zend.c:850
#12 0x082ba99a in php_request_shutdown (dummy=0x0)
at /home/dmitry/php/php5.2/main/main.c:1300
#13 0x0838631e in main (argc=4, argv=0xbf804304)
at /home/dmitry/php/php5.2/sapi/cgi/cgi_main.c:1792
--
Edit bug report at http://bugs.php.net/?id=39602&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39602&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39602&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39602&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39602&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39602&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39602&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39602&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39602&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39602&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39602&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39602&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39602&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39602&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39602&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39602&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39602&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39602&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39602&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39602&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39602&r=mysqlcfg
