[PHP-BUG] Bug #65481 [NEW]: Shutdown segfault due to serialize
From: mike Operating system: PHP version: 5.4Git-2013-08-19 (Git) Package: Variables related Bug Type: Bug Bug description:Shutdown segfault due to serialize Description: See the bottom of bug #63481 -- Edit bug report at https://bugs.php.net/bug.php?id=65481&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65481&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65481&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65481&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65481&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65481&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65481&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65481&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65481&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65481&r=support Expected behavior: https://bugs.php.net/fix.php?id=65481&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65481&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65481&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65481&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65481&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65481&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65481&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65481&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65481&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65481&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65481&r=mysqlcfg
Bug #63976 [PATCH]: Parent class incorrectly using child constant in class property
Edit report at https://bugs.php.net/bug.php?id=63976&edit=1 ID: 63976 Patch added by: m...@php.net Reported by:don at smugmug dot com Summary:Parent class incorrectly using child constant in class property Status: Assigned Type: Bug Package:Class/Object related Operating System: Ubuntu 12.04 PHP Version:5.4.10 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: zend_do_fetch_constant Revision: 1363687163 URL: https://bugs.php.net/patch-display.php?bug=63976&patch=zend_do_fetch_constant&revision=1363687163 Previous Comments: [2013-03-18 13:09:52] dmi...@php.net I understood the problem and your patch, I also agree what it fixes the problem for this particular case. Unfortunately, I afraid that it may break some applications, because it may make constant resolution early in the moment, when such constants were not defined yet. For example your patch is going to break the following script. I think the problem may be solved by substituting "self" and "parent" by actual class names at compile-time. It must be quite easy to do it for "self" (in zend_do_fetch_constant or in zend_do_declare_property), but not so easy for "parent" (we may use CG(parent_class_name) to solve it). [2013-03-14 17:42:39] don at smugmug dot com I have validated that the patch solves our use case (and the test case in this bug). Thanks Mike! -------- [2013-03-14 09:01:59] m...@php.net @dmitry, can you have a look at the , please? The condition could actually be simplified to if (ce->type == ZEND_USER_CLASS) ... Thank you. ---- [2013-02-14 17:30:36] m...@php.net The following patch has been added/updated: Patch Name: update_class_constants Revision: 1360863036 URL: https://bugs.php.net/patch-display.php?bug=63976&patch=update_class_constants&revision=1360863036 [2013-01-12 03:53:33] don at smugmug dot com 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. 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 https://bugs.php.net/bug.php?id=63976 -- Edit this bug report at https://bugs.php.net/bug.php?id=63976&edit=1
Bug #63976 [PATCH]: Parent class incorrectly using child constant in class property
Edit report at https://bugs.php.net/bug.php?id=63976&edit=1 ID: 63976 Patch added by: m...@php.net Reported by:don at smugmug dot com Summary:Parent class incorrectly using child constant in class property Status: Open Type: Bug Package:Class/Object related Operating System: Ubuntu 12.04 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: update_class_constants Revision: 1360863036 URL: https://bugs.php.net/patch-display.php?bug=63976&patch=update_class_constants&revision=1360863036 Previous Comments: [2013-01-12 03:53:33] don at smugmug dot com 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. [2013-01-12 03:51:21] don at smugmug dot com Description: Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: Consistent results for Baz->table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz->table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz->table == 'foo' in the examples). Actual result: -- brokenA.php: Bar Object ( [table] => bar ) Baz Object ( [table] => foo ) brokenB.php: Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) brokenC.php: Baz Object ( [table] => baz ) Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) -- Edit this bug report at https://bugs.php.net/bug.php?id=63976&edit=1
Bug #64146 [PATCH]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
Patch added by: m...@php.net
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
Status: Verified
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: zend_objects_get_address
Revision: 1360277847
URL:
https://bugs.php.net/patch-display.php?bug=64146&patch=zend_objects_get_address&revision=1360277847
Previous Comments:
[2013-02-07 21:35:26] m...@php.net
Obviously a flaw in the way an object is identified in the engine/in the
serializer.
Since the cloned objects only live for the time of serialization, both have the
same object handle and will be identified as the *same*.
Not sure why unserialize barfs on it, though.
[2013-02-07 19:37:35] ni...@php.net
@slusarz: Github changed the Gist URLs to include the owner's name too. I guess
they didn't consider users having number-names while doing that ^^
[2013-02-07 17:18:06] slusarz at curecanti dot org
Strange... Since that is the link github provides when you click on "share".
Anyway, try this instead:
https://gist.github.com/slusarz/4709613
[2013-02-07 16:05:15] larue...@php.net
the link says: 4709613 hasn't created any public gists yet.
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
[PHP-BUG] Bug #63726 [NEW]: Memleak with static properties and internal/user classes
From: mike
Operating system: Arch Linux
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Memleak with static properties and internal/user classes
Description:
There may occur memory leaks, if a user class extends an internal class
with
modified static properties:
â ~/build/php-5.4-dbg-zts-gcov$ sapi/cli/php -r
'http\Object::setDefaultErrorHandling(http\Object::EH_NORMAL);'
â ~/build/php-5.4-dbg-zts-gcov$ sapi/cli/php -r
'http\Object::setDefaultErrorHandling(http\Object::EH_NORMAL); class eh
extends
http\Object{}'
[Sat Dec 8 11:50:14 2012] Script: '-'
/home/mike/src/php-5.4-workdir/Zend/zend_API.c(3756) : Freeing
0x7FC747BCE318
(32 bytes), script=-
=== Total 1 memory leaks detected ===
http\Object::setDefaultErrorHandling() just does a
zend_update_static_property_long()
Test script:
---
Actual result:
--
[Sat Dec 8 11:50:14 2012] Script: '-'
/home/mike/src/php-5.4-workdir/Zend/zend_API.c(3756) : Freeing
0x7FC747BCE318
(32 bytes), script=-
=== Total 1 memory leaks detected ===
--
Edit bug report at https://bugs.php.net/bug.php?id=63726&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63726&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63726&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63726&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63726&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63726&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63726&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63726&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63726&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63726&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63726&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63726&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63726&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63726&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63726&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63726&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63726&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63726&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63726&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63726&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63726&r=mysqlcfg
[PHP-BUG] Bug #60933 [NEW]: Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
From: mgdm
Operating system: Mac OS X 10.6
PHP version: 5.4SVN-2012-01-30 (SVN)
Package: Arrays related
Bug Type: Bug
Bug description:Testing asort with SORT_LOCALE_STRING fails on Mac OS X 10.6
Description:
The test ext/standard/tests/array/locale_sort.phpt fails.
"Ãle-du-Prince-Ãdouard"
is sorted to the end of the array, instead of the expected 3rd position.
Test script:
---
"Alberta",
"BC" => "Colombie-Britannique",
"MB" => "Manitoba",
"NB" => "Nouveau-Brunswick",
"NL" => "Terre-Neuve-et-Labrador",
"NS" => "Nouvelle-Ãcosse",
"ON" => "Ontario",
"PE" => "Ãle-du-Prince-Ãdouard",
"QC" => "Québec",
"SK" => "Saskatchewan",
"NT" => "Territoires du Nord-Ouest",
"NU" => "Nunavut",
"YT" => "Territoire du Yukon");
asort($table, SORT_LOCALE_STRING);
var_dump($table);
Expected result:
array(13) {
["AB"]=>
string(7) "Alberta"
["BC"]=>
string(20) "Colombie-Britannique"
["PE"]=>
string(21) "Ãle-du-Prince-Ãdouard"
["MB"]=>
string(8) "Manitoba"
["NB"]=>
string(17) "Nouveau-Brunswick"
["NS"]=>
string(15) "Nouvelle-Ãcosse"
["NU"]=>
string(7) "Nunavut"
["ON"]=>
string(7) "Ontario"
["QC"]=>
string(6) "Québec"
["SK"]=>
string(12) "Saskatchewan"
["NL"]=>
string(23) "Terre-Neuve-et-Labrador"
["YT"]=>
string(19) "Territoire du Yukon"
["NT"]=>
string(25) "Territoires du Nord-Ouest"
Actual result:
--
array(13) {
["AB"]=>
string(7) "Alberta"
["BC"]=>
string(20) "Colombie-Britannique"
["MB"]=>
string(8) "Manitoba"
["NB"]=>
string(17) "Nouveau-Brunswick"
["NS"]=>
string(15) "Nouvelle-Ãcosse"
["NU"]=>
string(7) "Nunavut"
["ON"]=>
Bug #55801 [PATCH]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1 ID: 55801 Patch added by: m...@php.net Reported by:mapi at pdepend dot org Summary:Behavior of unserialize has changed Status: Feedback Type: Bug Package:Variables related Operating System: Linux (Fedora 15) PHP Version:5.4.0beta1 Assigned To:mike Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318522878 URL: https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318522878 Previous Comments: [2011-10-13 14:39:40] m...@php.net Could you try attached patch, please? [2011-10-13 14:39:10] m...@php.net The following patch has been added/updated: Patch Name: fix-serialize-in-sleep-and-wakeup Revision: 1318516750 URL: https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318516750 [2011-10-04 16:34:49] mapi at pdepend dot org To answer your question, I did't know my initial intention about the __temp__ property, but I remember that there was a reason. But it seems that this property is obsolete now. [2011-10-04 16:20:39] mapi at pdepend dot org Cool that you came up with a reproducable, I have tried it for a couple of hours and didn't get a working reproducable outside of PHP_Depend. But is it such an uncommon use case to serialize/unserialize additional data in an object's __sleep() or __wakeup() method? ---- [2011-10-04 14:20:46] m...@php.net So, after digging a lot, I can only see two solutions: - either disallow serialize/unserialize in __sleep/__wakeup - or revert r299770 which introduced a "persistent" state for serialize() which allowed objects which implement the Serializable interface to keep reference info through recursive calls to serialize(), see FR #36424 The issue can probably be seen as follows: serialize(obj) -> obj->__sleep does serialize() (in your code) -> then internally serialize(obj->prop) happens unserialize(obj) -> internally unserialize(obj->prop) is done -> obj->__wakeup is called which does unserialize() (your code) As you can see the IDs of the referenced objects when unserializing cannot match the IDs at serialization time, because of the mixed up call order. 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 https://bugs.php.net/bug.php?id=55801 -- Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Bug #55801 [PATCH]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1
ID: 55801
Patch added by: m...@php.net
Reported by:mapi at pdepend dot org
Summary:Behavior of unserialize has changed
Status: Analyzed
Type: Bug
Package:Variables related
Operating System: Linux (Fedora 15)
PHP Version:5.4.0beta1
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-serialize-in-sleep-and-wakeup
Revision: 1318516750
URL:
https://bugs.php.net/patch-display.php?bug=55801&patch=fix-serialize-in-sleep-and-wakeup&revision=1318516750
Previous Comments:
[2011-10-04 16:34:49] mapi at pdepend dot org
To answer your question, I did't know my initial intention about the __temp__
property, but I remember that there was a reason. But it seems that this
property
is obsolete now.
[2011-10-04 16:20:39] mapi at pdepend dot org
Cool that you came up with a reproducable, I have tried it for a couple of
hours
and didn't get a working reproducable outside of PHP_Depend.
But is it such an uncommon use case to serialize/unserialize additional data in
an object's __sleep() or __wakeup() method?
----
[2011-10-04 14:20:46] m...@php.net
So, after digging a lot, I can only see two solutions:
- either disallow serialize/unserialize in __sleep/__wakeup
- or revert r299770 which introduced a "persistent" state for serialize()
which
allowed objects which implement the Serializable interface to keep reference
info through recursive calls to serialize(), see FR #36424
The issue can probably be seen as follows:
serialize(obj)
-> obj->__sleep does serialize() (in your code)
-> then internally serialize(obj->prop) happens
unserialize(obj)
-> internally unserialize(obj->prop) is done
-> obj->__wakeup is called which does unserialize() (your code)
As you can see the IDs of the referenced objects when unserializing cannot
match
the IDs at serialization time, because of the mixed up call order.
--------
[2011-10-04 08:25:40] m...@php.net
Ok, now got a reproduce case:
parent ? $this->parent . "/" . $this->path : $this->path;
}
function __construct(node $parent = null, $path = ".") {
$this->parent = $parent;
$this->path = $path;
if (is_dir($this)) foreach (scandir($this) as $p) {
if ($p[0] != ".") {
$this->nodes[] = new node($this, $p);
}
}
}
function __sleep() {
$this->temp = serialize($this->nodes);
return array("path", "temp");
}
function __wakeup() {
$this->nodes = unserialize($this->temp);
$this->temp = null;
foreach ($this->nodes as $n) {
$n->parent = $this;
}
}
function createWeirdConnections() {
foreach ($this->nodes as $n) {
$a = $this->nodes;
shuffle($a);
$n->nodes[] = current($a);
}
}
}
$tree = new node(null, @$_SERVER["argv"][1] ?: ".");
$tree->createWeirdConnections();
$s = serialize($tree);
$temp = unserialize($s);
[2011-10-03 11:41:36] m...@php.net
OTOH, the following working script suggests that this is not the source of
failure:
parent ? $this->parent . "/" . $this->path : $this->path;
}
function __construct(node $parent = null, $path = ".") {
$this->parent = $parent;
$this->path = $path;
if (is_dir($this)) foreach (scandir($this) as $p) {
if ($p[0] != ".") {
$this->nodes[] = new node($this, $p);
}
}
}
function __sleep() {
$this->temp = serialize($this->nodes);
return array("path", "temp");
}
function __wakeup() {
$this->nodes = unserialize($this->temp);
$this->temp = null;
foreach ($this->nodes as $n) {
$n->parent = $this;
}
}
}
$tree = new node(null, @$_SERVER["argv"][1] ?: ".");
$s = serialize($tree);
var_dump($s);
$temp = unserialize($s);
print_r($temp);
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
https://bugs.php.net/bug.php?id=55801
--
Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Bug #52395 [Com]: ftp_connect only uses DNS hostnames
Edit report at http://bugs.php.net/bug.php?id=52395&edit=1 ID: 52395 Comment by: m...@php.net Reported by: john-ubuntu at cornerstonelinux dot co dot uk Summary: ftp_connect only uses DNS hostnames Status: Open Type: Bug Package: FTP related Operating System: Ubuntu 10.04 PHP Version: 5.3.2 New Comment: I just tried that using Ubuntu's PHP on 10.04, and it doesn't have that problem. Neither does a plain PHP. Are you sure it's not something local to your setup (like the FTP server listening on a v4 address and PHP resolving localhost to v6?) Previous Comments: [2010-07-21 22:12:33] john-ubuntu at cornerstonelinux dot co dot uk New description with better line wrapping: If "localhost" is present in /etc/hosts but does not resolve via DNS then ftp_connect will not connect to it. Most well setup DNS systems will have a "localhost." zone that resolves to 127.0.0.1, but this is not compulsory and some ISPs do not do this. It is traditional for UNIX systems to be able to use local names as defined in /etc/hosts for basic names resolution before DNS. This bug does not appear to occur in other PHP network functions such as IMAP or SMTP, and did not appear in PHP 5.2.4 on Ubuntu 8.04 (and earlier). I first noticed this bug when I upgrade a mail server from Ubuntu 8.04 to Ubuntu 10.04 and the Squirrelmail autorespond plugin (which uses ftp_connect) reported a "failed to connect" error. To replicate this problem you will have to test on a system that does not resolve "localhost" via DNS. Use the "host" command to check you can not do this: $ host -v localhost Trying "localhost.uk.fabit.net" Trying "localhost" Host localhost not found: 3(NXDOMAIN) [2010-07-21 22:09:42] john-ubuntu at cornerstonelinux dot co dot uk Description: If "localhost" is present in /etc/hosts but does not resolve via DNS then ftp_c\ onnect will not connect to it. Most well setup DNS systems will have a "localhost." zone that resolves to 127.\ 0.0.1, but this is not compulsory and some ISPs do not do this. It is traditional for UNIX systems to be able to use local names as defined in \ /etc/hosts for basic names resolution before DNS. This bug does not appear to occur in other PHP network functions such as IMAP o\ r SMTP, and did not appear in PHP 5.2.4 on Ubuntu 8.04 (and earlier). I first noticed this bug when I upgrade a mail server from Ubuntu 8.04 to Ubunt\ u 10.04 and the Squirrelmail autorespond plugin (which uses ftp_connect) report\ ed a "failed to connect" error. To replicate this problem you will have to test on a system that does not resol\ ve "localhost" via DNS. Use the "host" command to check you can not do this: $ host -v localhost Trying "localhost.uk.fabit.net" Trying "localhost" Host localhost not found: 3(NXDOMAIN) Test script: --- Expected result: An ftp connection with no error message. Actual result: -- No ftp connection attempt and my error message "FTP connection failed". -- Edit this bug report at http://bugs.php.net/bug.php?id=52395&edit=1
Bug #51903 [PATCH]: simplexml_load_file() doesn't use HTTP headers
Edit report at http://bugs.php.net/bug.php?id=51903&edit=1
ID: 51903
Patch added by: m...@php.net
Reported by:phpwnd at gmail dot com
Summary:simplexml_load_file() doesn't use HTTP headers
Status: Open
Type: Bug
Package:SimpleXML related
PHP Version:5.3.2
New Comment:
The following patch has been added/updated:
Patch Name: check_stream-wrapperdata_for_encoding
Revision: 1274878924
URL:
http://bugs.php.net/patch-display.php?bug=51903&patch=check_stream-wrapperdata_for_encoding&revision=1274878924
Previous Comments:
[2010-05-25 07:16:56] phpwnd at gmail dot com
Description:
Seen at http://stackoverflow.com/questions/2899274/
If you use simplexml_load_file() to load a remote document via HTTP,
SimpleXML assumes that the content is UTF-8 regardless of the HTTP
headers. In the test script below, at the time of writing, Google's web
server returns something like:
-
HTTP/1.1 200 OK
Content-Type: text/xml; charset=GB2312
Date: Tue, 25 May 2010 05:05:17 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
expires=Thu, 24-May-2012 05:05:17 GMT; path=/; domain=.google.com
X-Content-Type-Options: nosniff
Server: igfe
X-XSS-Protection: 1; mode=block
Transfer-Encoding: chunked
-
The server advertises the content "text/xml; charset=GB2312", but since
the XML declaration doesn't mention the encoding, SimpleXML assumes it
is UTF-8 and eventually fails to load it.
If it is at all possible, SimpleXML (and DOM, I assume) should look at
the HTTP headers to find the document's encoding.
Test script:
---
simplexml_load_file('http://www.google.com/ig/api?weather=11791&hl=zh-CN');
Actual result:
--
PHP Warning: simplexml_load_file():
http://www.google.com/ig/api?weather=11791&hl=zh-CN:1: parser error :
Input is not proper UTF-8, indicate encoding !
Bytes: 0xC7 0xE7 0x22 0x2F in Command line code on line 1
Warning: simplexml_load_file():
http://www.google.com/ig/api?weather=11791&hl=zh-CN:1: parser error :
Input is not proper UTF-8, indicate encoding !
Bytes: 0xC7 0xE7 0x22 0x2F in Command line code on line 1
PHP Warning: simplexml_load_file(): t_system
data="SI"/>http://bugs.php.net/bug.php?id=51903&edit=1
Bug #51581 [PATCH]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Patch added by: m...@php.net Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties Status: Open Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: fix-reflection-of-default-static-members Revision: 1273671935 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-reflection-of-default-static-members&revision=1273671935 Previous Comments: [2010-05-12 15:42:00] m...@php.net The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
Bug #51581 [PATCH]: getDefaultProperties incorrect for static properties
Edit report at http://bugs.php.net/bug.php?id=51581&edit=1 ID: 51581 Patch added by: m...@php.net Reported by: ChadFulton at gmail dot com Summary: getDefaultProperties incorrect for static properties Status: Open Type: Bug Package: Reflection related Operating System: Mac OSx 10.6 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: fix-refs-to-default-static-members Revision: 1273671720 URL: http://bugs.php.net/patch-display.php?bug=51581&patch=fix-refs-to-default-static-members&revision=1273671720 Previous Comments: [2010-04-17 02:24:07] ChadFulton at gmail dot com Description: The array ReflectionClass's getDefaultProperties() method changes for static properties, depending upon what value the static property currently holds. I suppose there is an argument to be made that this is expected/desired, since static properties are meant to hold across all instances of the class. However, it doesn't seem like it necessarily fits as part of a function to get the *default* property. Test script: --- getDefaultProperties()); foo::$bar = 'new static value, no longer default though'; print_r($r->getDefaultProperties()); ?> Expected result: Array ( [bar] => true default value ) Array ( [bar] => true default value ) Actual result: -- Array ( [bar] => true default value ) Array ( [bar] => new static value, no longer default though ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51581&edit=1
Bug #51725 [PATCH]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Patch added by: m...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Verified Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273656982 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273656982 Previous Comments: [2010-05-12 11:11:53] m...@php.net The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273655513 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273655513 [2010-05-03 15:32:16] il...@php.net IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
Bug #51725 [PATCH]: xmlrpc_get_type() returns true on invalid dates
Edit report at http://bugs.php.net/bug.php?id=51725&edit=1 ID: 51725 Patch added by: m...@php.net Reported by: geiss...@php.net Summary: xmlrpc_get_type() returns true on invalid dates Status: Verified Type: Bug Package: XMLRPC-EPI related Operating System: linux/kfreebsd ia64/x86_64 PHP Version: 5.3.2 New Comment: The following patch has been added/updated: Patch Name: php_parse_date-return-on-parse-error Revision: 1273655513 URL: http://bugs.php.net/patch-display.php?bug=51725&patch=php_parse_date-return-on-parse-error&revision=1273655513 Previous Comments: [2010-05-03 15:32:16] il...@php.net IT happens on 64bit systems only. The reason has to do with date extension, which is used to validate the date string (on 64 bit machines this results in a very small negative #), not -1 and thus passed validation. [2010-05-03 14:23:18] fel...@php.net (I tested on 32bit though) [2010-05-03 14:20:36] fel...@php.net I cannot reproduce it on Linux using: libexpat1-dev --- 2.0.1-4+lenny3 libxml2-dev--- 2.7.3.dfsg-2.1 [2010-05-03 05:40:35] geiss...@php.net Description: ext/xmlrpc/tests/bug42189.phpt fails consistently on 64 bits architectures such as ia64 and x86_64. I modified the test a bit to show what's going on. From a quick look at the code it appears to be a bug in the XMLRPC-EPI lib and not in the module itself. Test script: --- Expected result: bool(false) Done Actual result: -- bool(true) ~~ Done -- Edit this bug report at http://bugs.php.net/bug.php?id=51725&edit=1
