php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52604 Serialization of objects with __sleep() and fatal error
Submitted: 2010-08-14 09:40 UTC Modified: 2013-06-27 21:22 UTC
Votes:17
Avg. Score:4.5 ± 0.9
Reproduced:16 of 16 (100.0%)
Same Version:3 (18.8%)
Same OS:2 (12.5%)
From: zerspam at mail dot ru Assigned:
Status: Not a bug Package: Session related
PHP Version: Irrelevant OS: irrelevant
Private report: No CVE-ID: None
 [2010-08-14 09:40 UTC] zerspam at mail dot ru
Description:
------------
Seems like __sleep() does not being invoked when fatal error was risen.

Test script:
---------------
	set_error_handler('my_error_handler');

	session_start();

	$obj = new myclass();

	$_SESSION['obj'] = $obj;

	$a->b();

	class myclass
	{
		private $a = 1;
		private $b = 2;
		
		public function __sleep()
		{
			return array('a');
		}
	}

	function my_error_handler($code, $error, $file = NULL, $line = NULL)
	{
		throw new ErrorException($error, $code, 0, $file, $line);
	}

Expected result:
----------------
Object with only 'a' property in session file

Actual result:
--------------
Object with 'a' and 'b' properties in session file

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-05 13:32 UTC] zerspam at mail dot ru
Well, 3 weeks left and even no comments from dev team?
 [2010-09-14 04:43 UTC] isaiah dot derosewilson at kohanaphp dot com
I also have this same problem. I've tested both php 5.2.12 and 5.3.3 and neither of them correctly serialize the object when there is a fatal error - the whole object gets serialized when there is a fatal error instead of just the properties in __sleep(). However if your class implements Serializable everything works as expected when there is a fatal error.
 [2010-10-12 14:24 UTC] tony2001@php.net
-Status: Open +Status: Bogus
 [2010-10-12 14:24 UTC] tony2001@php.net
>However if your class implements Serializable everything works as 
>expected when there is a fatal error.

Not true.
See this example:
---------
set_error_handler('my_error_handler');                                          
session_start();                                                                $a->b();                                                                        class myclass implements Serializable                                                                                        
{                                                                                   private $a= 1;                          
    private $b = 2;

  public function serialize()
{                                                                                       var_dump("serialize");               
        return serialize(array('a'));
}                                                                                   public function unserialize($data)                                                              {                                                                                       var_dump("unserialize");
        return unserialize($data);
}                                                                                                                        
}                                                                               

function my_error_handler($code, $error, $file = NULL, $line = NULL)                                                         
{                                                                                   throw new ErrorException($error, $code, 0, $file, $line);
}                                                                               
$obj = new myclass();                                   
$_SESSION['obj'] = $obj;
---------

Whether your class implements Serializable or not, serializers are called on _request shutdown_ which never happens in case of fatal error, because fatal error means BOOM!, exit.

And to be honest, I don't see anything wrong here.
Your script FAILED with a fatal error, did you expect PHP to ignore it an go on running?
 [2010-10-12 14:44 UTC] zerspam at mail dot ru
Uhm, in any case: wherther it is a error or not - I expected php does not broke my data. And I cannot get how your sample related to mine.

With my code you can see that php stores the data it should not store. And it is a error.
 [2010-10-13 08:10 UTC] mike@php.net
-Status: Bogus +Status: Re-Opened
 [2010-10-13 08:10 UTC] mike@php.net
Tony, if your argument would be valid, there wouldn't be anything in the serssion at all, sould it?
 [2010-10-13 08:11 UTC] mike@php.net
-Status: Re-Opened +Status: Open
 [2010-10-31 00:19 UTC] isaiah dot derosewilson at kohanaphp dot com
Tony, I guess I didn't explain myself very well. Serializable isn't the problem. The issue is with the __wakeup/__sleep() methods.

Let's take these two example classes:
---------------
class myclass implements Serializable {
	 private $a = 1;
         private $b = 2;

	public function serialize()
	{
             return serialize(array('a' => $this->a));
	}

	public function unserialize($data)
	{
                foreach(unserialize($data) as $name => $var)
		{
			$this->{$name} = $var;
		}
	}
}

class myclass2 {
	private $a = 1;
        private $b = 2;

	public function __sleep()
	{
		return array('a');
	}

	public function __wakeup()
	{

	}
}

I would expect both classes to serialize the 'a' property and they both do. However when there is a fatal error in your code (like your example code), both the a and b properties from the myclass2 class are serialized.

Here is an example of my session data using your example code and the two classes above.

Using Serializable:
obj|C:7:"myclass":18:{a:1:{s:1:"a";i:1;}} (without exception)
obj|N; (with exception)

Using sleep/wakeup:
obj|O:8:"myclass2":1:{s:11:"myclass2a";i:1;} (without exception)
obj|O:8:"myclass2":2:{s:11:"myclass2a";i:1;s:11:"myclass2b";i:2;} (with exception)

Notice how when using the __sleep/__wakeup methods the whole object is stored instead of nothing (or just the data in the __sleep method). Hopefully that explains the issue a little better.
 [2013-06-27 21:22 UTC] arpad@php.net
-Status: Open +Status: Not a bug
 [2013-06-27 21:22 UTC] arpad@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 06:01:29 2024 UTC