Is it about objects being serialized and stored using 5.3 and unserialized using 
5.4? And it fails to unserialize them?

Or are you doing this proecess manually?

No it's about large object trees serialized in PHP 5.4 and unserialized with the 
same version. This has worked with all PHP versions < 5.4. 

It seems that these object trees are now unserialized or serialized or destructed 
in a different order, so that some of the previous objects are now NULL.

What PHP_Depend does is serializing double linked object trees like. It uses 
__sleep() to reset the child-parent link before a tree gets serialized:

class Node {
    protected $parent;
    protected $nodes = array();

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

And it uses __wakeup() to restore this link during the unserialization:

class Node {
    protected $parent;
    protected $nodes = array();

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

    public function __wakeup() {
        foreach ($this->nodes as $node) {
            $node->parent = $this;
        }
    }
}

Now it seems that under certain circumstances the $this->nodes property is an 
array when __wakeup() is called, but instead of objects the array values are 
NULL.

This happens when the following PHP Warning occurs:

PHP Warning:  Creating default object from empty value 
in /tmp/pdepend/src/main/php/PHP/Depend/Code/ASTNode.php on line 569

Hm, hard to find what failed without an example then. Can you try to create a 
script to generate an object tree and un/serialize it? That will be very helpful 
to fix this problem.

I will try to create a reproducable.

Okay, I tried for several hours to create a reproducable outside of PHP_Depend's 
context, but I cannot reproduce this behavior :(

But at least I came up with a small code fragement that illustrates this 
behavior:

  <?php
  class Test {
      function method() {   
          $this->prop[$y]++;
      }
  }

which was translated into the following object graph:

 Statement
   Expression
     MemberPrimaryPrefix  <----------
       Variable                     |
       PropertyPostfix              |
         ArrayIndexExpression  [Same Instance]
           Identifier               |
           Variable                 |
     PostfixExpression              |
       MemberPrimaryPrefix ----------
         Variable
         PropertyPostfix
           ArrayIndexExpression
             Identifier
             Variable

And this second reference to MemberPrimaryPrefix is NULL after unserialization 
with PHP 5.4 and it is just a second clone with PHP < 5.4

Any chance to get something that shows us the serialized data with 5.4 and 5.4 so 
we can see how they differ?

Maybe upload the small possible code somewhere?

Yes, here you can get the two serialized object structures:

http://manuel-pichler.de/stuff/5.3.ser
http://manuel-pichler.de/stuff/5.4.ser

And there is the difference:

5.3 -> *nodes";a:1:{i:0;r:18;}}}}}}}}}
5.4 -> *nodes";a:1:{i:0;r:36;}}}}}}}}}

It references something different.

It seems that this has something todo with the visibility of properties that 
should be serialized. If I do the following:

~ $ rm -rf ~/.pdepend
~ $ git clone https://github.com/pdepend/pdepend.git
~ $ cd pdepend
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +86
    -> Change from PROTECTED to PUBLIC
       protected $parentClassReference = null; -> public $parentClassReference = 
null;
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +132
    -> Change from PROTECTED to PUBLIC
       protected $nodes = array(); -> public $nodes = array();
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml 
src/main/php/PHP/Depend/Code/ASTArrayType.php
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml 
src/main/php/PHP/Depend/Code/ASTArrayType.php
...
Executing CyclomaticComplexity-Analyzer:

Fatal error: Call to a member function findChildrenOfType() on a non-object in 
/tmp/pdepend/src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php on line 
268

If I now revert the visibility of both properties from PUBLIC to PROTECTED, it 
works:

~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +86
    -> Change from PUBLIC to PROTECTED
       public $parentClassReference = null; -> protected $parentClassReference = 
null;
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +132
    -> Change from PUBLIC to PROTECTED
       public $nodes = array(); -> protected $nodes = array();
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml 
src/main/php/PHP/Depend/Code/ASTArrayType.php

This means that a PUBLIC property that was serialized can be restored in a 
PROTECTED property while unserializing the object structure.

Can you try reverting SVN revision r299770 and then run your test? - That's mostly a guess, though.

bug #36424
http://svn.php.net/viewvc/?view=revision&revision=299770

Bingo! 

With revision 299770 this bug occurs the first time. If I checkout and compile 
revision 299769 of trunk, everything works as expected. With revision 299770 I 
get those annoying unserialized arrays with NULL values.

mike, seems like you broke this. Please take a look.

Obviously I did, but it's unclear how...
The reproduce case doesn't help much either.

Ok, I think I found the problematic POC: 
in line 486 of PHP_Depend_Code_AbstractCallable you call serialize() while 
another (the prime) serialize calls __sleep() on an instance of this class.

What's the intention of this __temp__ thing?

OTOH, the following working script suggests that this is not the source of 
failure:


<?php

class node {
    public $parent;
    public $nodes = array();
    public $path;
    public $temp;

    function __toString() {
        return $this->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);

Ok, now got a reproduce case:

<?php

class node {
    protected $parent;
    protected $nodes = array();
    protected $path;
    protected $temp;

    function __toString() {
        return $this->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);

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.

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?

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.

Could you try attached patch, please?

So? Running your original test script seems to work fine with this patch...

Hello Mike,

I just tested a patched version of "branches/PHP_5_4/" and "trunk/" with the 
original implementation that uses serialize() and unserialize() within 
__sleep()/__wakeup(). Everything works as expected and there are no NULL filled 
arrays anymore.

Thank you very much for help

This bug has been fixed in SVN.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.