#40422 [Bgs]: script breaks memory limit
ID: 40422 User updated by: mb at nasa30 dot com Reported By: mb at nasa30 dot com Status: Bogus Bug Type: Reproducible crash Operating System: Windows 2003 server standart PHP Version: 5.2.1 New Comment: With PHP 5.2.0 it worked! There was no error caused by the memory limit. There is something changed from 5.2.0 to 5.2.1 Previous Comments: [2007-02-09 23:21:15] [EMAIL PROTECTED] Memory limit was not enabled on Win32 before. [2007-02-09 23:20:44] [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. [2007-02-09 23:19:51] mb at nasa30 dot com I use Apache 2.2.4 [2007-02-09 23:16:51] mb at nasa30 dot com Description: My simple benchmark script breaks the memory limit what it did never before. I tested it on my w2k3 server. I normaly use 8 MB as memory limit. which is enough for my apps. But Now the script end in a fatal error even when I set it up to 64 MB. Reproduce code: --- http://www.source-center.de/forum/showthread.php?t=27651 Expected result: Finish: 1171062920 Result: 10 sekunden Actual result: -- Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 256 bytes) in C:\server2\www\benchmark.php on line 115 -- Edit this bug report at http://bugs.php.net/?id=40422edit=1
#40429 [NEW]: headers sent when using php://output + ob_start
From: nicolas dot grekas+php at gmail dot com
Operating system: WIN
PHP version: 5.2.1
PHP Bug Type: Streams related
Bug description: headers sent when using php://output + ob_start
Description:
Opening the php://output stream seams to flag the headers as sent, event
if output buffering is on. Consequently, any call to header() fails where
it shouldn't.
Affects any extension that uses streams.
Reproduce code:
---
?php
ob_start();
$h = fopen('php://output', 'wb');
fclose($h);
ob_end_clean();
header('X-Foo: bar');
?
Or
?php
ob_start();
$dom = new DOMDocument;
$dom-save('php://output');
ob_end_clean();
header('X-Foo: bar');
?
Expected result:
blank page
Actual result:
--
Warning: Cannot modify header information - headers already sent in
C:\[...]\test.php on line 8
--
Edit bug report at http://bugs.php.net/?id=40429edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40429r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40429r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40429r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40429r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40429r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40429r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40429r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40429r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40429r=support
Expected behavior:http://bugs.php.net/fix.php?id=40429r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40429r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40429r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40429r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40429r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40429r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40429r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40429r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40429r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40429r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40429r=mysqlcfg
#40430 [NEW]: timeout parameter for function file()
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.4.4 PHP Bug Type: Feature/Change Request Bug description: timeout parameter for function file() Description: When you use file() to get a file over a network (internet) like file(http://www.php.net;); you will get an timeout error if there is no connection to the internet or the requested URL. There I suggest to add an additional (optional) attribute int timeout to this function, making php cancel the function call after x seconds. -- Edit bug report at http://bugs.php.net/?id=40430edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40430r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40430r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40430r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40430r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40430r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40430r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40430r=needscript Try newer version:http://bugs.php.net/fix.php?id=40430r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40430r=support Expected behavior:http://bugs.php.net/fix.php?id=40430r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40430r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40430r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40430r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40430r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40430r=dst IIS Stability:http://bugs.php.net/fix.php?id=40430r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40430r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40430r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40430r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40430r=mysqlcfg
#40430 [Opn-Csd]: timeout parameter for function file()
ID: 40430 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.4.4 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php There already is a timeout http context option in 5.2.1 Previous Comments: [2007-02-10 13:21:12] [EMAIL PROTECTED] Description: When you use file() to get a file over a network (internet) like file(http://www.php.net;); you will get an timeout error if there is no connection to the internet or the requested URL. There I suggest to add an additional (optional) attribute int timeout to this function, making php cancel the function call after x seconds. -- Edit this bug report at http://bugs.php.net/?id=40430edit=1
#39381 [Bgs-Opn]: __destruct bug
ID: 39381
Updated by: [EMAIL PROTECTED]
Reported By: tikitiki at mybboard dot com
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Not Applicable
PHP Version: 5.2.0
New Comment:
This one has hit me using the PEAR HTTP_Session class using the PEAR DB
driver. No sessions were being stored in the database.
Previous Comments:
[2006-11-13 15:54:00] tikitiki at mybboard dot com
C'mon Guys... Hear me out here.
The classes in PHP 5.2.0 have been changed to destruct in the reverse
order that they've been initialized. Why I ask? I hope the change was
not 'just because'. And if the change was intentional, you guys should
have known that it would affect many scripts. Does it not make more
sense to destruct classes in the order they were initialized in the
first place?
[2006-11-12 16:57:38] rygorde4 at sbcglobal dot net
this is a PHP 5.2.0 error which causes the classes to be destructed in
the reverse way they are initialized. If this change was intended for
PHP 5.2.0, then you should have given us a heads up before you went
releasing software that broke a whole ton of scripts.
This IS a error on PHP 5.2.0, the PHP team should consider unbogusing
the report.
[2006-11-11 00:58:58] rygorde4 at sbcglobal dot net
http://bugs.php.net/bug.php?id=36759 ???
How come it is different in PHP 5.2.0? A lot of programs are corrupt
because of this 'change'.
Will being able to call register_shutdown_function on __destruct fix
this, regardless of php version?
[2006-11-10 16:15:58] [EMAIL PROTECTED]
There is no certain order of object destruction, there never was and
this is explained in many other reports.
You have to take care of the correct destruction order yourself.
[2006-11-10 16:08:11] tikitiki at mybboard dot com
Reproduce code:
---
?php
function run_shutdown() {
global $x;
echo __FUNCTION__.\n;
$x-do_something();
}
class Foo {
function do_something() {
echo hi\n;
}
function __destruct() {
echo __METHOD__.\n;
}
}
class Bar {
function __destruct() {
run_shutdown();
echo __METHOD__.\n;
}
}
$y = new Bar();
$x = new Foo();
?
Expected result:
Bar::__destruct
run_shutdown
hi
Foo::__destruct
Actual result:
--
Foo::__destruct
run_shutdown
Fatal error: Call to a member function do_something() on a non-object
in C:\Program Files\Apache Software
Foundation\Apache2.2\htdocs\test.php on line 5
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/39381
--
Edit this bug report at http://bugs.php.net/?id=39381edit=1
#40431 [NEW]: ReflectionProperty::isStatic() returns true for overloaded properties
From: bugs at forestfactory dot de
Operating system: Windows XP SP2
PHP version: 4CVS-2007-02-10 (CVS)
PHP Bug Type: Class/Object related
Bug description: ReflectionProperty::isStatic() returns true for overloaded
properties
Description:
For stdClass objects, ReflectionProperty::isStatic() returns true for all
properties.
Code has two examples, the first one showing the bug, the second one
showing the expected result.
Reproduce code:
---
?php
// Creating Obj with new doesn't affect this bug
/* $Obj = new stdClass; */
$Obj-value = 'value';
$RefObj = new ReflectionObject($Obj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(true)
}
// Reflection works for this class
class myClass extends stdClass {
}
$MyObj = new myClass;
$MyObj-value = 'value';
$RefObj = new ReflectionObject($MyObj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(false)
}
?
Expected result:
both var_dump's should print bool(false)
Actual result:
--
stdClass::$value is said to be static
--
Edit bug report at http://bugs.php.net/?id=40431edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40431r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40431r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40431r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40431r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40431r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40431r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40431r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40431r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40431r=support
Expected behavior:http://bugs.php.net/fix.php?id=40431r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40431r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40431r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40431r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40431r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40431r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40431r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40431r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40431r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40431r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40431r=mysqlcfg
#40432 [NEW]: strip_tags() fails with greater than in attribute
From: geoffers at gmail dot com
Operating system: Mac OS 10.4.8
PHP version: 5.2.1
PHP Bug Type: Strings related
Bug description: strip_tags() fails with greater than in attribute
Description:
The following valid (X)HTML is not stripped (this has been
reported before and closed claiming it is invalid read the
SGML and XML specifications this is completely valid).
Reproduce code:
---
?php
echo strip_tags('span title=test allthis/span');
?
Expected result:
this
Actual result:
--
allthis
--
Edit bug report at http://bugs.php.net/?id=40432edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40432r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40432r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40432r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40432r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40432r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40432r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40432r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40432r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40432r=support
Expected behavior:http://bugs.php.net/fix.php?id=40432r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40432r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40432r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40432r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40432r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40432r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40432r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40432r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40432r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40432r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40432r=mysqlcfg
#40432 [Opn-Asn]: strip_tags() fails with greater than in attribute
ID: 40432
Updated by: [EMAIL PROTECTED]
Reported By: geoffers at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Strings related
Operating System: Mac OS 10.4.8
PHP Version: 5.2.1
-Assigned To:
+Assigned To: iliaa
Previous Comments:
[2007-02-10 15:46:13] geoffers at gmail dot com
Description:
The following valid (X)HTML is not stripped (this has been
reported before and closed claiming it is invalid read the
SGML and XML specifications this is completely valid).
Reproduce code:
---
?php
echo strip_tags('span title=test allthis/span');
?
Expected result:
this
Actual result:
--
allthis
--
Edit this bug report at http://bugs.php.net/?id=40432edit=1
#40417 [Opn-Bgs]: Suddenly binding as many vars as there are *identical* prepared tokens
ID: 40417
Updated by: [EMAIL PROTECTED]
Reported By: exaton at free dot fr
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Windows XP Pro SP2
PHP Version: 5.2.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When you have multiple instances of :id they count as one
token since they reference the same bound parameter.
Previous Comments:
[2007-02-09 17:25:31] exaton at free dot fr
All right, here you go, but it's really because I love you guys :)
So, still comparing PHP 5.2.0 and PHP 5.2.1 on Windows XP Pro SP2 with
a PostgreSQL 8.1.5 backend.
From phpinfo() concerning pdo_pgsql :
PHP 5.2.0 :
PostgreSQL(libpq) Version 8.1.4
Module version 1.0.2
Revision$Id: pdo_pgsql.c,v 1.7.2.11 2006/03/14 10:49:18 edink Exp $
PHP 5.2.1 :
PostgreSQL(libpq) Version 8.1.4
Module version 1.0.2
Revision$Id: pdo_pgsql.c,v 1.7.2.11.2.1 2007/01/01 09:36:05 sebastian
Exp $
So the difference is just in the revision of pdo_pgsql.c .
Now for the test case ; I'll even give you a test table :
CREATE TABLE t (
id INTEGER PRIMARY KEY,
s TEXTNOT NULL
);
INSERT INTO t (id, s) VALUES (1, 'foo');
INSERT INTO t (id, s) VALUES (2, 'bar');
INSERT INTO t (id, s) VALUES (3, 'doh');
INSERT INTO t (id, s) VALUES (4, 'duh');
And here's the PHP code :
// Connect to database
// Let $DATA be the resulting PDO object
$sta = $DATA - prepare('SELECT id, s FROM t WHERE id = :id OR id =
:id'); // notice 2 identical ':id' tokens
$sta - bindValue(':id', 2, PDO :: PARAM_INT); // bind ':id' a single
time, of course
$sta - execute(); // this is line #12
$arr = $sta - fetch(PDO :: FETCH_ASSOC);
echo pre;
print_r($arr);
echo /pre;
/* Expected (as obtained in PHP 5.2.0) :
Array
(
[id] = 2
[s] = bar
)
*/
/* Obtained in PHP 5.2.1 :
PDOException
thrown at ...\bug.php(12)
SQLSTATE[HY093]: Invalid parameter number: number of bound variables
does
not match number of tokens
#0 ...\bug.php(12):
PDOStatement-execute()
#1 {main}
*/
Binding an extra token (to make up the 2 tokens in the prepared
statement, even though they are identical) will work around the problem
:
$sta - bindValue(':xyz', 42, PDO :: PARAM_INT);
I think it should complain that the :xyz token is not to be found in
the statement in the first place, but anyway (it doesn't make that
complaint in PHP 5.2.0 either).
By adding that line before the call to execute(), the expected result
is obtained.
Hope this helps !
[2007-02-09 16:58:09] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-02-09 16:39:14] exaton at free dot fr
Description:
I have just upgraded from PHP 5.2.0 to PHP 5.2.1, and one of my scripts
has broken on the following point (note, the backend database is
PostgreSQL 8.1.5) :
Consider this prepared statement query, automatically generated as part
of a basic search engine operating on a table of shops :
SELECT indx, name, town FROM shops WHERE enabled AND (lower(name) LIKE
:word0 OR lower(address) LIKE :word0 OR lower(town) LIKE :word0 OR
lower(company) LIKE :word0 OR lower(description) LIKE :word0) ORDER BY
name;
You notice that 5 ':word0' tokens are defined. I then proceed to bind
':word0' to a certain value (individual $word taken from a search
field), *a single time* of course :
$shops - bindValue(':word'.$i, '%'.$word.'%'); // $i = 0
Up to PHP 5.2.0, this worked as expected. Now in PHP 5.2.1 I am getting
a PDOException : SQLSTATE[HY093]: Invalid parameter number: number of
bound variables does
not match number of tokens.
To work around this problem, I indeed have to call bindValue() as many
times as there are tokens (5 in this example), even though those tokens
are identical. As a consequence, the name of the extra *fictitious*
bound tokens does not matter, except that binding 5 times the same
token name (e.g. 5 times ':word0') does not work. But binding ':word0'
to ':word4' does, for instance.
I have noticed some similarity with PHP bug #33886, but I believe this
to be a slightly
#40417 [Bgs-Opn]: Suddenly binding as many vars as there are *identical* prepared tokens
ID: 40417
User updated by: exaton at free dot fr
Reported By: exaton at free dot fr
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Windows XP Pro SP2
PHP Version: 5.2.1
New Comment:
I'm sorry, but I don't understand your reply.
Perhaps my use of the word token is wrong. The multiple instances
count[ing] as one token, since they reference the same bound
parameter is exactly the behaviour I expect, and had been counting on
*and getting* up to now.
However, Re. my initial example and test case, *several bindings* are
required, *as many as there are _instances_*, not just tokens. This is
what is happening in PHP 5.2.1.
1) It differs from what I believe we both understand to be the correct
behaviour.
2) Even if binding as many times as there are *instances* of tokens
were the correct behaviour, we would have to conclude that the
implementation was flawed up to PHP 5.2.0, because *existing code*
breaks with the upgrade to PHP 5.2.1.
My apologies again for insisting, but I think we're both on the same
track here, with PHP 5.2.1 having introduced an incoherence on this
point (maybe the code in pdo_pgsql.c compares the number of effective
bindings to the number of :token instances instead of the number of
effectively different tokens...).
Previous Comments:
[2007-02-10 16:07:29] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When you have multiple instances of :id they count as one
token since they reference the same bound parameter.
[2007-02-09 17:25:31] exaton at free dot fr
All right, here you go, but it's really because I love you guys :)
So, still comparing PHP 5.2.0 and PHP 5.2.1 on Windows XP Pro SP2 with
a PostgreSQL 8.1.5 backend.
From phpinfo() concerning pdo_pgsql :
PHP 5.2.0 :
PostgreSQL(libpq) Version 8.1.4
Module version 1.0.2
Revision$Id: pdo_pgsql.c,v 1.7.2.11 2006/03/14 10:49:18 edink Exp $
PHP 5.2.1 :
PostgreSQL(libpq) Version 8.1.4
Module version 1.0.2
Revision$Id: pdo_pgsql.c,v 1.7.2.11.2.1 2007/01/01 09:36:05 sebastian
Exp $
So the difference is just in the revision of pdo_pgsql.c .
Now for the test case ; I'll even give you a test table :
CREATE TABLE t (
id INTEGER PRIMARY KEY,
s TEXTNOT NULL
);
INSERT INTO t (id, s) VALUES (1, 'foo');
INSERT INTO t (id, s) VALUES (2, 'bar');
INSERT INTO t (id, s) VALUES (3, 'doh');
INSERT INTO t (id, s) VALUES (4, 'duh');
And here's the PHP code :
// Connect to database
// Let $DATA be the resulting PDO object
$sta = $DATA - prepare('SELECT id, s FROM t WHERE id = :id OR id =
:id'); // notice 2 identical ':id' tokens
$sta - bindValue(':id', 2, PDO :: PARAM_INT); // bind ':id' a single
time, of course
$sta - execute(); // this is line #12
$arr = $sta - fetch(PDO :: FETCH_ASSOC);
echo pre;
print_r($arr);
echo /pre;
/* Expected (as obtained in PHP 5.2.0) :
Array
(
[id] = 2
[s] = bar
)
*/
/* Obtained in PHP 5.2.1 :
PDOException
thrown at ...\bug.php(12)
SQLSTATE[HY093]: Invalid parameter number: number of bound variables
does
not match number of tokens
#0 ...\bug.php(12):
PDOStatement-execute()
#1 {main}
*/
Binding an extra token (to make up the 2 tokens in the prepared
statement, even though they are identical) will work around the problem
:
$sta - bindValue(':xyz', 42, PDO :: PARAM_INT);
I think it should complain that the :xyz token is not to be found in
the statement in the first place, but anyway (it doesn't make that
complaint in PHP 5.2.0 either).
By adding that line before the call to execute(), the expected result
is obtained.
Hope this helps !
[2007-02-09 16:58:09] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-02-09 16:39:14] exaton at free dot fr
Description:
I have just upgraded from PHP 5.2.0 to PHP 5.2.1, and one of my scripts
has broken on the following point (note, the backend database is
PostgreSQL 8.1.5) :
Consider this prepared statement query,
#40417 [Opn]: Suddenly binding as many vars as there are *identical* prepared tokens
ID: 40417
User updated by: exaton at free dot fr
Reported By: exaton at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP Pro SP2
PHP Version: 5.2.1
New Comment:
OK, I've taken a look at the source code to try and lend a hand in
clearing up this issue. My first time though, so here's hoping I'm not
too far off the mark.
Diffing ext/pdo/ and ext/pdo_pgsql/ files between PHP 5.2.0 and 5.2.1,
I find that the error message I am encountering is due to a new
paragraph having been *added* to the much remangled
ext/pdo/pdo_sql_parser.c (line 262) :
if (params bindno != zend_hash_num_elements(params)
stmt-supports_placeholders == PDO_PLACEHOLDER_NONE) {
pdo_raise_impl_error(stmt-dbh, stmt, HY093, number of bound
variables does not match number of tokens TSRMLS_CC);
ret = -1;
goto clean_up;
}
Somehow I'm trigerring the error condition, here. I'm guessing that my
bindno is different from the number of elements in the params hash
table.
bindno is incremented on line 214. I could be wrong, but I'm under the
impression that it is *incremented with each _placeholder_*, which in
turn I take to be the token *instances* we were talking about
before.
Now, I think we both agree that we only have to bind as many
values/vars as there are *different* tokens in the statement. That is
in any case how things worked up to PHP 5.2.0.
With the new error detection that has been added (the above paragraph
of code), and if I'm right about the way bindno is counted, then we are
expected to bind as many values/vars as there are *placeholders* in the
statement, even if there are 2 or more placeholders for the same token
name.
That would be very coherent with the new error I am getting. It would
also be coherent with my workaround, in which one just had to bind
extra, bogus values/vars (thus artificially filling up the params hash
table, with params = stmt - bound_params) in order to not get this
error.
So :
1) The new error detection breaks existing scripts that worked with
5.2.0.
2) I think we agree that the specification introduced by this new error
detection is incorrect. One may, as far as I know, use several times the
same placeholder for bound values/vars in a statement. It is only
possible to bind a given token once (because that binding fills a hash
table, which will of course not increase in size if the same token is
bound several times). Therefore, forcing one to bind as many
values/vars as there are *placeholders* is surely incorrect.
3) The workaround is symptomatic of something real fishy going on
(having to write bogus code to unblock a piece of functionality,
wt... ?).
That's as much as I can do guys, I have no setup whatsoever for tracing
variables in the code. The object of such a trace would be to confirm
that, with my test case (in which there are 2 identical :id
placeholders in the statement), bindno = 2 versus only 1 entry in the
params = stmt - bound_params hash table.
Good luck, and thank you for your patience, I'm not much good at
writing simple sentences :)
Previous Comments:
[2007-02-10 16:18:08] exaton at free dot fr
I'm sorry, but I don't understand your reply.
Perhaps my use of the word token is wrong. The multiple instances
count[ing] as one token, since they reference the same bound
parameter is exactly the behaviour I expect, and had been counting on
*and getting* up to now.
However, Re. my initial example and test case, *several bindings* are
required, *as many as there are _instances_*, not just tokens. This is
what is happening in PHP 5.2.1.
1) It differs from what I believe we both understand to be the correct
behaviour.
2) Even if binding as many times as there are *instances* of tokens
were the correct behaviour, we would have to conclude that the
implementation was flawed up to PHP 5.2.0, because *existing code*
breaks with the upgrade to PHP 5.2.1.
My apologies again for insisting, but I think we're both on the same
track here, with PHP 5.2.1 having introduced an incoherence on this
point (maybe the code in pdo_pgsql.c compares the number of effective
bindings to the number of :token instances instead of the number of
effectively different tokens...).
[2007-02-10 16:07:29] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When you have multiple instances of :id they count as one
token since they reference the same bound parameter.
[2007-02-09 17:25:31] exaton at free dot fr
All right, here you go, but it's really because I love you guys :)
So, still comparing PHP 5.2.0
#40421 [Opn-Asn]: Install error 2343
ID: 40421 Updated by: [EMAIL PROTECTED] Reported By: wade_link at hotmail dot com -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: XP Pro PHP Version: 5.2.1 -Assigned To: +Assigned To: jmertic Previous Comments: [2007-02-10 00:09:58] wade_link at hotmail dot com It worked sort of. It got most of the way through the intall then errored. It had the same error message. It gets through a lot, but the error message shows up when it says it is writing INI files. [2007-02-09 23:37:58] [EMAIL PROTECTED] Please try: http://downloads.php.net/edink/php-5.2.1-win32-installer-fix.msi [2007-02-09 23:24:34] [EMAIL PROTECTED] So 5.2.1 _probably_ works fine, but you can't test it because you cannot uninstall the previous version. Consult your OS support on how to force the uninstall? [2007-02-09 23:20:06] wade_link at hotmail dot com Well, not exactly. I just downloaded php-5.2.1-win32-installer and tried that, but it give me the message that there is a previous version installed and it must be un-installed before the new version can be installed. Back to square one. [2007-02-09 23:16:38] [EMAIL PROTECTED] Yeah, there is a good chance 5.2.1 will work fine. 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/40421 -- Edit this bug report at http://bugs.php.net/?id=40421edit=1
#40326 [Fbk-Opn]: Can't open file from cwd if parent folder not readable
ID: 40326 User updated by: sborrill at precedence dot co dot uk Reported By: sborrill at precedence dot co dot uk -Status: Feedback +Status: Open Bug Type: Streams related Operating System: NetBSD 3.1_STABLE PHP Version: 5.2.0 New Comment: Yes, as per my original bug report, it is not fixed in the daily snapshots. I've confirmed it today's too. I can recreate it with the cli php binary too (i.e. I don't have to test it from Apache). Previous Comments: [2007-02-05 13:51:27] [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 [2007-02-05 13:45:38] sborrill at precedence dot co dot uk OK, permissions are nearly the same (except in our case, it's the parent of the www directory that is -r not the www itself, but that's probably unimportant). The getcwd() line shows a difference though. On NetBSD and other Unix OSes (all except for Linux?) getcwd() returns FALSE as noted in http://bugs.php.net/bug.php?id=24185 Perhaps the reason it's working for you on Linux is because your getcwd() _isn't_ returning FALSE and there's now an extra getcwd() call in the fopen codepath. N.B. as in my original report, with PHP 5.1.6, getcwd() returned FALSE, but fopen worked nonetheless. Also, the patches to PHP in the NetBSD package are the same between 5.1.6 and 5.2.0 (or if they differ it's in an unrelated section). The patches related to php.ini, configure, curl and imap/c-client only. Everything else is stock: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/php5/patches/ [2007-02-05 09:40:56] [EMAIL PROTECTED] What OS? Linux Are you sure you've checked file ownership? #ls -ld /www d--x--x--x 15 tony users 2864 Feb 5 12:36 /www #ls -l /www/index.php -rw-r--r-- 1 tony users 110 Feb 5 12:36 /www/index.php Apache runs as user wwwrun. What do you get on the getcwd() lines? string(4) /www Please try the latest snapshot from http://snaps.php.net if you're using some patches/adopted version. [2007-02-03 09:32:00] sborrill at precedence dot co dot uk What OS? Are you sure you've checked file ownership? What do you get on the getcwd() lines? We are finding this is 100% reproducible on all our customers' servers when they are using php in a UserDir. I've checked the package definition and patches at: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/php5/ Nothing relevant has been altered betweeen 5.1.6 and 5.2.0 in the NetBSD pkg. php.ini file remains the same throughout. We aren't using safe mode or open_basedir. I looked at the CVS log for fopen_wrapper.c but didn't spot anything relevant. I'm not familiar enough with PHP internals to know where to add much debugging, but I'm happy to follow any suggestions. [2007-02-02 18:44:36] [EMAIL PROTECTED] Cannot reproduce. Both PHP 5.2-CVS and PHP 6-CVS work just fine with Apache 1.x. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40326 -- Edit this bug report at http://bugs.php.net/?id=40326edit=1
#40431 [Opn-Asn]: ReflectionProperty::isStatic() returns true for overloaded properties
ID: 40431
Updated by: [EMAIL PROTECTED]
Reported By: bugs at forestfactory dot de
-Status: Open
+Status: Assigned
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 4CVS-2007-02-10 (CVS)
-Assigned To:
+Assigned To: tony2001
Previous Comments:
[2007-02-10 15:09:02] bugs at forestfactory dot de
Description:
For stdClass objects, ReflectionProperty::isStatic() returns true for
all properties.
Code has two examples, the first one showing the bug, the second one
showing the expected result.
Reproduce code:
---
?php
// Creating Obj with new doesn't affect this bug
/* $Obj = new stdClass; */
$Obj-value = 'value';
$RefObj = new ReflectionObject($Obj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(true)
}
// Reflection works for this class
class myClass extends stdClass {
}
$MyObj = new myClass;
$MyObj-value = 'value';
$RefObj = new ReflectionObject($MyObj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(false)
}
?
Expected result:
both var_dump's should print bool(false)
Actual result:
--
stdClass::$value is said to be static
--
Edit this bug report at http://bugs.php.net/?id=40431edit=1
#40427 [Opn-Bgs]: fsockopen() always forces a DNS resolution unnecessarily
ID: 40427
Updated by: [EMAIL PROTECTED]
Reported By: andrew at neonsurge dot com
-Status: Open
+Status: Bogus
Bug Type: Streams related
Operating System: Gentoo, OS-X 10.4
PHP Version: 5.2.1
New Comment:
fsockopen() always asks your DNS server for the IP address
of a connection before it opens it, instead of trying to
look in the local cache first.
Believe me, fsockopen() knows nothing about DNS servers and local
caches.
Not PHP problem.
Previous Comments:
[2007-02-10 02:33:25] andrew at neonsurge dot com
Description:
fsockopen() always asks your DNS server for the IP address
of a connection before it opens it, instead of trying to
look in the local cache first. I believe this is unexpected
and performance-wise is a very undesirable operation. See
reproduce code...
Reproduce code:
---
?php for ($i = 0; $i 50; $i++) {
$errno = $errstr = ;
//$ip = gethostbyname(php.net); $a =
fsockopen($ip,22,$errno,$errstr,10); //FAST way
$a = fsockopen(php.net,22,$errno,$errstr,10); //SLOW way
$ab = fread($a,4096); unset($a, $ab);
} ?
Expected result:
While running the slower code above exactly as
is, you can packet sniff and view 50 full requests for the
domain php.net. This is unoptimized and causes this code to
run extremely slow.
When running with the fast way (change lines commented out)
the above code runs a few hundred percent faster. Upon a
packet sniff you can watch 1 or two requests for php.net
being sent to your DNS server which I believe is the desired
result.
NOTE: In the code above I do have the workaround by
connecting with the IP instead by using gethostbyname()
first which appears to use the local DNS cache.
Actual result:
--
The code above should run exactly the same speed either way.
fsockopen should be using the local machine's DNS cache and
not have to query the DNS server upon every request when
given a DNS name to connect to.
--
Edit this bug report at http://bugs.php.net/?id=40427edit=1
#40431 [Asn-Csd]: ReflectionProperty::isStatic() returns true for overloaded properties
ID: 40431
Updated by: [EMAIL PROTECTED]
Reported By: bugs at forestfactory dot de
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 4CVS-2007-02-10 (CVS)
Assigned To: tony2001
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-02-10 15:09:02] bugs at forestfactory dot de
Description:
For stdClass objects, ReflectionProperty::isStatic() returns true for
all properties.
Code has two examples, the first one showing the bug, the second one
showing the expected result.
Reproduce code:
---
?php
// Creating Obj with new doesn't affect this bug
/* $Obj = new stdClass; */
$Obj-value = 'value';
$RefObj = new ReflectionObject($Obj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(true)
}
// Reflection works for this class
class myClass extends stdClass {
}
$MyObj = new myClass;
$MyObj-value = 'value';
$RefObj = new ReflectionObject($MyObj);
foreach ($RefObj-getProperties() as $Property) {
var_dump($Property-isStatic()); // prints bool(false)
}
?
Expected result:
both var_dump's should print bool(false)
Actual result:
--
stdClass::$value is said to be static
--
Edit this bug report at http://bugs.php.net/?id=40431edit=1
#39381 [Opn-Bgs]: __destruct bug
ID: 39381 Updated by: [EMAIL PROTECTED] Reported By: tikitiki at mybboard dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Not Applicable PHP Version: 5.2.0 New Comment: HTTP_Session and DB are php4-based code with no __destruct() methods. moving back to bogus as the last comment relates to a different issue (shutdown functions) and not to class destructors. It would be better to write an email to [EMAIL PROTECTED] asking for assistance with this issue, to determine whether there is a bug in HTTP_Session, or perhaps DB, before reporting again as a PHP bug Previous Comments: [2007-02-10 14:42:09] [EMAIL PROTECTED] This one has hit me using the PEAR HTTP_Session class using the PEAR DB driver. No sessions were being stored in the database. [2006-11-13 15:54:00] tikitiki at mybboard dot com C'mon Guys... Hear me out here. The classes in PHP 5.2.0 have been changed to destruct in the reverse order that they've been initialized. Why I ask? I hope the change was not 'just because'. And if the change was intentional, you guys should have known that it would affect many scripts. Does it not make more sense to destruct classes in the order they were initialized in the first place? [2006-11-12 16:57:38] rygorde4 at sbcglobal dot net this is a PHP 5.2.0 error which causes the classes to be destructed in the reverse way they are initialized. If this change was intended for PHP 5.2.0, then you should have given us a heads up before you went releasing software that broke a whole ton of scripts. This IS a error on PHP 5.2.0, the PHP team should consider unbogusing the report. [2006-11-11 00:58:58] rygorde4 at sbcglobal dot net http://bugs.php.net/bug.php?id=36759 ??? How come it is different in PHP 5.2.0? A lot of programs are corrupt because of this 'change'. Will being able to call register_shutdown_function on __destruct fix this, regardless of php version? [2006-11-10 16:15:58] [EMAIL PROTECTED] There is no certain order of object destruction, there never was and this is explained in many other reports. You have to take care of the correct destruction order yourself. 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/39381 -- Edit this bug report at http://bugs.php.net/?id=39381edit=1
#40326 [Opn]: Can't open file from cwd if parent folder not readable
ID: 40326 User updated by: sborrill at precedence dot co dot uk Reported By: sborrill at precedence dot co dot uk Status: Open Bug Type: Streams related Operating System: NetBSD 3.1_STABLE PHP Version: 5.2.0 New Comment: I've tracked this down to changes to virtual_file_ex() which is called from expand_filepath(). expand_filepath() returns /file from file with 5.2.0 (and later), but returns file with 5.1.6 and earlier. This is down to changes between revisions 1.74.2.9 (v5.1.6) and 1.74.2.9.2.9 (v5.2.0) of TSRM/tsrm_virtual_cwd.c. I've not yet tracked it down further. Previous Comments: [2007-02-10 19:25:28] sborrill at precedence dot co dot uk Yes, as per my original bug report, it is not fixed in the daily snapshots. I've confirmed it today's too. I can recreate it with the cli php binary too (i.e. I don't have to test it from Apache). [2007-02-05 13:51:27] [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 [2007-02-05 13:45:38] sborrill at precedence dot co dot uk OK, permissions are nearly the same (except in our case, it's the parent of the www directory that is -r not the www itself, but that's probably unimportant). The getcwd() line shows a difference though. On NetBSD and other Unix OSes (all except for Linux?) getcwd() returns FALSE as noted in http://bugs.php.net/bug.php?id=24185 Perhaps the reason it's working for you on Linux is because your getcwd() _isn't_ returning FALSE and there's now an extra getcwd() call in the fopen codepath. N.B. as in my original report, with PHP 5.1.6, getcwd() returned FALSE, but fopen worked nonetheless. Also, the patches to PHP in the NetBSD package are the same between 5.1.6 and 5.2.0 (or if they differ it's in an unrelated section). The patches related to php.ini, configure, curl and imap/c-client only. Everything else is stock: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/php5/patches/ [2007-02-05 09:40:56] [EMAIL PROTECTED] What OS? Linux Are you sure you've checked file ownership? #ls -ld /www d--x--x--x 15 tony users 2864 Feb 5 12:36 /www #ls -l /www/index.php -rw-r--r-- 1 tony users 110 Feb 5 12:36 /www/index.php Apache runs as user wwwrun. What do you get on the getcwd() lines? string(4) /www Please try the latest snapshot from http://snaps.php.net if you're using some patches/adopted version. [2007-02-03 09:32:00] sborrill at precedence dot co dot uk What OS? Are you sure you've checked file ownership? What do you get on the getcwd() lines? We are finding this is 100% reproducible on all our customers' servers when they are using php in a UserDir. I've checked the package definition and patches at: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/php5/ Nothing relevant has been altered betweeen 5.1.6 and 5.2.0 in the NetBSD pkg. php.ini file remains the same throughout. We aren't using safe mode or open_basedir. I looked at the CVS log for fopen_wrapper.c but didn't spot anything relevant. I'm not familiar enough with PHP internals to know where to add much debugging, but I'm happy to follow any suggestions. 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/40326 -- Edit this bug report at http://bugs.php.net/?id=40326edit=1
#40433 [NEW]: SimpleXML enforces wrong charset
From: consensus at gmail dot com Operating system: any PHP version: 5.2.1 PHP Bug Type: SimpleXML related Bug description: SimpleXML enforces wrong charset Description: SimpleXML has a wrong behaviour (yes it is defined, but still wrong) regarding the charset. SimpleXML is able to read any xml file as long as the charset is given in the xml header (encoding=...) But when it gives back values it does not recognize the encoding anymore and forces utf-8. While this might be defined behaviour it is still a very unclean/ignorant feature. It is the only function i know which behaves like this. Charsets do have their good reason. and ofcourse you can convert each value you get into the correct charset. But here why this is generally a bad idea: a) Everyone expects the function to not change the charset. b) This is a big waste of cputime. If you have millions of values you have millions of function calls to reconvert them all! Depending on the application you write this can get a real problem. I suggest to rethink about this design decision as it will be a problem for many others too over the time. -- Edit bug report at http://bugs.php.net/?id=40433edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40433r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40433r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40433r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40433r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40433r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40433r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40433r=needscript Try newer version:http://bugs.php.net/fix.php?id=40433r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40433r=support Expected behavior:http://bugs.php.net/fix.php?id=40433r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40433r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40433r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40433r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40433r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40433r=dst IIS Stability:http://bugs.php.net/fix.php?id=40433r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40433r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40433r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40433r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40433r=mysqlcfg
#38051 [Com]: changing upload_max_filesize in php.ini has no effect
ID: 38051 Comment by: ilyas at foxplan dot com Reported By: saurabh_barjatiya at daiict dot ac dot in Status: No Feedback Bug Type: *Configuration Issues Operating System: Fedora Core 5 PHP Version: 5.1.4 New Comment: I had the same problem inn IIS 5.0. I noticed that IIS was picking php.ini from c:\program files\php folder instead of c:\php where I expected it to be. When I changed php.ini in c:\program files\php folder, I had the desitred result. just check your PC incase there is another installation of php. Previous Comments: [2006-12-26 00:33:22] marek dot zolkowski at gmail dot com I found an error in my php.ini file... there were 1 not necessary in file. Problem solved... [2006-12-23 17:17:21] ZavPublic at mac dot com I believe this is fixed in PHP 5.1.6 [2006-12-21 18:02:24] marek dot zolkowski at gmail dot com I've got the same problem: any changes in section File Uploads has no effect (upload_max_filesize and upload_tmp_dir) I'm using php 5.2.0-8 in apache-ssl on Debian. It happens after upgreading php from php4 to php5. Before this upgrade I could upload larger files and there was everything ok... Can anyone help me? [2006-11-06 17:00:42] zavpublic at mac dot com Same issue for me in 5.1.4 Using php 5.1.4 in MAMP on a Quad G5 under Mac OS X 10.4.8. [2006-07-18 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/38051 -- Edit this bug report at http://bugs.php.net/?id=38051edit=1
#40433 [Opn-Bgs]: SimpleXML enforces wrong charset
ID: 40433 Updated by: [EMAIL PROTECTED] Reported By: consensus at gmail dot com -Status: Open +Status: Bogus Bug Type: SimpleXML related Operating System: any PHP Version: 5.2.1 New Comment: Yes, it's defined behaviour and will stay that way. About the waste of cpu cycles. The library used for SimpleXML (and all other XML extensions) is libxml2 and this library does convert anything internally to UTF-8, regardless what the input is. So, you have to convert it back to whatever charset you want in your PHP script Previous Comments: [2007-02-10 22:07:20] consensus at gmail dot com Description: SimpleXML has a wrong behaviour (yes it is defined, but still wrong) regarding the charset. SimpleXML is able to read any xml file as long as the charset is given in the xml header (encoding=...) But when it gives back values it does not recognize the encoding anymore and forces utf-8. While this might be defined behaviour it is still a very unclean/ignorant feature. It is the only function i know which behaves like this. Charsets do have their good reason. and ofcourse you can convert each value you get into the correct charset. But here why this is generally a bad idea: a) Everyone expects the function to not change the charset. b) This is a big waste of cputime. If you have millions of values you have millions of function calls to reconvert them all! Depending on the application you write this can get a real problem. I suggest to rethink about this design decision as it will be a problem for many others too over the time. -- Edit this bug report at http://bugs.php.net/?id=40433edit=1
#40434 [NEW]: Session engine can't access /var/tmp when safe mode is on
From: r2 at music dot lt Operating system: FreeBSD PHP version: 5.2.1 PHP Bug Type: Session related Bug description: Session engine can't access /var/tmp when safe mode is on Description: After upgrading from PHP 5.2 to PHP 5.2.1 error log is full of these lines: PHP Warning: session_start() [a href='function.session-start'function.session-start/a]: SAFE MODE Restriction in effect. The script whose uid is 80 is not allowed to access /var/tmp owned by uid 0 in /file/path.php on line 1038 PHP Fatal error: session_start() [a href='function.session-start'function.session-start/a]: Failed to initialize storage module: files (path: ) in /file/path.php on line 1038 safe mode is on, open_basedir includes /var/tmp, safe_mode_include_dir is set to /var/tmp Needed to turn off safe mode. -- Edit bug report at http://bugs.php.net/?id=40434edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40434r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40434r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40434r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40434r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40434r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40434r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40434r=needscript Try newer version:http://bugs.php.net/fix.php?id=40434r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40434r=support Expected behavior:http://bugs.php.net/fix.php?id=40434r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40434r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40434r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40434r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40434r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40434r=dst IIS Stability:http://bugs.php.net/fix.php?id=40434r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40434r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40434r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40434r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40434r=mysqlcfg
#40434 [Com]: Session engine can't access /var/tmp when safe mode is on
ID: 40434 Comment by: judas dot iscariote at gmail dot com Reported By: r2 at music dot lt Status: Open Bug Type: Session related Operating System: FreeBSD PHP Version: 5.2.1 New Comment: Is the session save path implicetely defined in a virtual host , php.ini or whatever.. if not.. try that Needed to turn off safe mode. Do yourself and your customers that favor, safe_mode is **gone**[1], as it is a broken security measure[2] [1] http://cvs.php.net/viewvc.cgi/php-src/NEWS?revision=1.2139view=markuppathrev=HEAD [2]http://ilia.ws/archives/18-PHPs-safe_mode-or-how-not-to-implement-security.html Previous Comments: [2007-02-10 23:37:39] r2 at music dot lt Description: After upgrading from PHP 5.2 to PHP 5.2.1 error log is full of these lines: PHP Warning: session_start() [a href='function.session-start'function.session-start/a]: SAFE MODE Restriction in effect. The script whose uid is 80 is not allowed to access /var/tmp owned by uid 0 in /file/path.php on line 1038 PHP Fatal error: session_start() [a href='function.session-start'function.session-start/a]: Failed to initialize storage module: files (path: ) in /file/path.php on line 1038 safe mode is on, open_basedir includes /var/tmp, safe_mode_include_dir is set to /var/tmp Needed to turn off safe mode. -- Edit this bug report at http://bugs.php.net/?id=40434edit=1
#40436 [NEW]: object references broken in 5.2.1
From: Jason at V7Studios dot com
Operating system: Windows
PHP version: 5.2.1
PHP Bug Type: Class/Object related
Bug description: object references broken in 5.2.1
Description:
A certain object reference situation that my code depends on has been
broken in 5.2.1 on *windows*. It works on my linux production server
running 5.2.1.
Thanks.
Reproduce code:
---
class Foo
{
private $params = array();
function __set($name, $value){
$this-params[$name] = $value;
}
function __get($name){
return $this-params[$name];
}
}
$foo = new Foo();
$ref = $foo-bar;
$ref = This is a test;
print($foo-bar);
Expected result:
It should print out This is a test
Actual result:
--
On windows, nothing is printed out. $foo-bar is not set.
--
Edit bug report at http://bugs.php.net/?id=40436edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40436r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40436r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40436r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40436r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40436r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40436r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40436r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40436r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40436r=support
Expected behavior:http://bugs.php.net/fix.php?id=40436r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40436r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40436r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40436r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40436r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40436r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40436r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40436r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40436r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40436r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40436r=mysqlcfg
