Bug #65724 [Com]: unserialize doesn't always restore referenced objects
Edit report at https://bugs.php.net/bug.php?id=65724edit=1
ID: 65724
Comment by: bixuehujin at gmail dot com
Reported by:niko dot sams at gmail dot com
Summary:unserialize doesn't always restore referenced
objects
Status: Open
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
Had a test on commit
@8f146c2(https://github.com/php/php-src/commit/8f146c2bb0dcba3307f08a839554be056e660f34),
segfault occurred.
Previous Comments:
[2013-09-20 12:34:47] niko dot sams at gmail dot com
Description:
when doing another unserialize that creates objects in an
Serializable::unserialize implementation things break, the 'parent' isn't
unserialized correctly.
ok: PHP 5.3.3-7+squeeze14
ok: PHP 5.3.10-1ubuntu3.6
fail: PHP 5.4.4-14+deb7u2
fail: PHP 5.5.3
See phpt test script:
http://paste.kde.org/p83ce39d0/
Test script:
---
class Bar {}
class Foo implements Serializable {
public $test;
public function __construct($test) { $this-test = $test; }
public function serialize()
{
return $this-test;
}
public function unserialize($serialized)
{
//the following line causes problems
unserialize('O:3:Bar:1:{s:4:bar1;O:3:Bar:0:{}}');
$this-test = $serialized;
}
}
$foo1 = new Foo('foo1');
$foo2 = new Foo('foo2');
$foo3 = new Foo('foo3');
$ar = array(
array(
'instance' = $foo1,
),
array(
'instance' = $foo2,
),
array(
'instance' = $foo3,
'parent' = $foo2
)
);
$ar = serialize($ar);
$ar = unserialize($ar);
print_r($ar);
Expected result:
[parent] = Foo Object ( [test] = foo2 ) )
Actual result:
--
[parent] = foo2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65724edit=1
Bug #65636 [Com]: Stream path cannot contail null char (chr(0))
Edit report at https://bugs.php.net/bug.php?id=65636edit=1 ID: 65636 Comment by: bixuehujin at gmail dot com Reported by:bilge at scriptfusion dot com Summary:Stream path cannot contail null char (chr(0)) Status: Open Type: Bug Package:Streams related Operating System: Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: AFAIK, it is not possible to contain null character in a filename path, this is not because of PHP but the OS. At the OS level, it seems no way to handle a file contains null characters. Previous Comments: [2013-09-08 23:02:36] bilge at scriptfusion dot com Description: Stream path can contain any character, whether URL encoded or not, except for the null character. Including a null character in the path raises the following error: file_get_contents() expects parameter 1 to be a valid path, string given Both the use case and test suite to support the claims above can be found at https://github.com/Bilge/VerbatimStream/tree/eb185806f9bea3ee65b7d0f3e42dcd27a7b40614 The use case is a custom stream wrapper that takes the path and converts it into a read-only data stream. The current workaround is to urlencode any path that contains nulls. However, this approach provides little benefit over the data wrapper. Being able to include nulls directly in the path would eliminate unnecessary url encoding and decoding in the custom wrapper implementation. Test script: --- file_get_contents(\000); //or file_get_contents(verbatim://\000); Expected result: No error. Actual result: -- file_get_contents() expects parameter 1 to be a valid path, string given -- Edit this bug report at https://bugs.php.net/bug.php?id=65636edit=1
Bug #65492 [Com]: Seeking beyond EOF leads to inconsistent results for key() and current()
Edit report at https://bugs.php.net/bug.php?id=65492edit=1 ID: 65492 Comment by: bixuehujin at gmail dot com Reported by:foo at example dot com Summary:Seeking beyond EOF leads to inconsistent results for key() and current() Status: Open Type: Bug Package:SPL related Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, the expect result should be: Expect result: string(4) foo string(4) bar Previous Comments: [2013-09-19 18:55:40] bixuehujin at gmail dot com Another inconsistent: Script: $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(0); var_dump($file-fgets()); $file-seek(1); var_dump($file-fgets()); Expect result: string(4) foo string(3) bar Actual result: -- string(4) foo string(3) baz BTW: --- The issue also existed in SplFileObject. [2013-08-21 06:56:34] foo at example dot com Sorry, the last line in the Test Script should read var_dump( $file-key(), $file-current() ); The problem does exist for fgetcsv() though, too. It will return NULL instead of the data at the last line. [2013-08-21 06:50:48] foo at example dot com Description: When seek()'ing beyond the end of file in an SplFileObject, SplFileObject::key() will return the number of the last line in the file but SplFileObject::current() will return false. This is inconsistent. Either SplFileObject::current() returns the content of the last line then, too. Or SplFileObject::key() should return false as well. As an alternative, SplFileObject::seek() could raise an OutOfBoundsException when trying to seek beyond EOF. Test script: --- $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(100); var_dump( $file-key(), $file-fgetcsv()); Expected result: int(2) baz or false false or OutOfBoundsException Actual result: -- int(2) NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=65492edit=1
Bug #65492 [Com]: Seeking beyond EOF leads to inconsistent results for key() and current()
Edit report at https://bugs.php.net/bug.php?id=65492edit=1 ID: 65492 Comment by: bixuehujin at gmail dot com Reported by:foo at example dot com Summary:Seeking beyond EOF leads to inconsistent results for key() and current() Status: Open Type: Bug Package:SPL related Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Another inconsistent: Script: $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(0); var_dump($file-fgets()); $file-seek(1); var_dump($file-fgets()); Expect result: string(4) foo string(3) bar Actual result: -- string(4) foo string(3) baz BTW: --- The issue also existed in SplFileObject. Previous Comments: [2013-08-21 06:56:34] foo at example dot com Sorry, the last line in the Test Script should read var_dump( $file-key(), $file-current() ); The problem does exist for fgetcsv() though, too. It will return NULL instead of the data at the last line. [2013-08-21 06:50:48] foo at example dot com Description: When seek()'ing beyond the end of file in an SplFileObject, SplFileObject::key() will return the number of the last line in the file but SplFileObject::current() will return false. This is inconsistent. Either SplFileObject::current() returns the content of the last line then, too. Or SplFileObject::key() should return false as well. As an alternative, SplFileObject::seek() could raise an OutOfBoundsException when trying to seek beyond EOF. Test script: --- $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(100); var_dump( $file-key(), $file-fgetcsv()); Expected result: int(2) baz or false false or OutOfBoundsException Actual result: -- int(2) NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=65492edit=1
Bug #65598 [Com]: Closure executed via static autoload incorrectly marked as static
Edit report at https://bugs.php.net/bug.php?id=65598edit=1
ID: 65598
Comment by: bixuehujin at gmail dot com
Reported by:php at davidstockton dot com
Summary:Closure executed via static autoload incorrectly
marked as static
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Centos 6
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Indeedï¼it is odd and out of expect.
AFAIK, there is no difference between create closure in static methods and
require a file that will create a closure. Because of the created closure in
both have the same scope.
Consider the following two examples:
1: create closure in static method
//main.php
class Test {
public static function createClosure() {
$c = function () {
//some code
};
return $c;
}
}
2: create closure in a single file and require it
//main.php
class Test {
public static function createClosure() {
require 'closure.php';
return $c;
}
}
//closure.php
$c = function () {
//some code
};
The both examples have the same behavior, and both scope of $c are Test.
But according to the invariants in Zend/zend_closures.c, say:
If the closure is unscoped, it has no bound object.
The the closure is scoped, it's either static or it's bound
see detail:
https://github.com/php/php-src/blob/47ee470992014c738891d05b5acc89c2de90f2ac/Zend/zend_closures.c#L483,L498
So the behavior of this issue is valid according to the invariants.
*By the way, i am also want to know why we should have the invariants.*
Previous Comments:
[2013-09-17 21:30:38] php at davidstockton dot com
The closure is not created in a static method, it's just loaded via an
autoloader
that happens to be static. Seems odd that we should expect different behavior
of the
code based on if the autoloader is static or non-static.
[2013-09-17 20:52:18] bixuehujin at gmail dot com
The reason is closures created in static methods are static, even without the
keyword.
see
https://github.com/php/php-src/blob/a447acdcc6f12ea3a5dcd22416cb033e62995935/Zend/tests/closure_045.phpt
[2013-08-30 23:55:29] php at davidstockton dot com
Description:
If I load a class via a static autoloader which has executable code (including
a
closure) and then try to bind the closure to an object of the class, I get a
warning and error:
Warning: Cannot bind an instance to a static closure
and
Fatal error: Using $this when not in object context
If I run the script directly (not via autoloader) everything works as expected.
If I make the autoloader non-static, everything works as expected.
Test script:
---
Sample contains two files, a static autoloader which will load the class file
and the class file which also contains executable code.
If the autoloader is a plain function or a non-static method then the code
works as expected. If the executable code is removed from the class file and
placed into the autoloader file, everything works as expected.
php Autoloader.php (bad behavior)
php ClosureBug.php (correct behavior)
https://gist.github.com/dstockto/6395158
Expected result:
42
Actual result:
--
Warning: Cannot bind an instance to a static closure in
/vagrant/src/Bug/ClosureBug.php on line 9
Fatal error: Using $this when not in object context in
/vagrant/src/Bug/ClosureBug.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=65598edit=1
Bug #65598 [Com]: Closure executed via static autoload incorrectly marked as static
Edit report at https://bugs.php.net/bug.php?id=65598edit=1 ID: 65598 Comment by: bixuehujin at gmail dot com Reported by:php at davidstockton dot com Summary:Closure executed via static autoload incorrectly marked as static Status: Open Type: Bug Package:Scripting Engine problem Operating System: Centos 6 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: The reason is closures created in static methods are static, even without the keyword. see https://github.com/php/php-src/blob/a447acdcc6f12ea3a5dcd22416cb033e62995935/Zend/tests/closure_045.phpt Previous Comments: [2013-08-30 23:55:29] php at davidstockton dot com Description: If I load a class via a static autoloader which has executable code (including a closure) and then try to bind the closure to an object of the class, I get a warning and error: Warning: Cannot bind an instance to a static closure and Fatal error: Using $this when not in object context If I run the script directly (not via autoloader) everything works as expected. If I make the autoloader non-static, everything works as expected. Test script: --- Sample contains two files, a static autoloader which will load the class file and the class file which also contains executable code. If the autoloader is a plain function or a non-static method then the code works as expected. If the executable code is removed from the class file and placed into the autoloader file, everything works as expected. php Autoloader.php (bad behavior) php ClosureBug.php (correct behavior) https://gist.github.com/dstockto/6395158 Expected result: 42 Actual result: -- Warning: Cannot bind an instance to a static closure in /vagrant/src/Bug/ClosureBug.php on line 9 Fatal error: Using $this when not in object context in /vagrant/src/Bug/ClosureBug.php on line 19 -- Edit this bug report at https://bugs.php.net/bug.php?id=65598edit=1
