the link says: 4709613 hasn't created any public gists yet.

Strange... Since that is the link github provides when you click on "share".

Anyway, try this instead:

https://gist.github.com/slusarz/4709613

@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 ^^

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.

Using zend_objects_get_address() instead of the object handle fixes; but triggers 
bug #62836

PHP 5.5.7 (the latest at this moment) fails its testsuite on a 32-bit architecture on this bug.  The reproduction build is very simple: ./configure --disable-all && make && make test .

According to Remi Collet this has started with PHP 5.5.5 and affects only 32-bit systems while 64-bit systems pass the test.  The latest reply on the PHP development list I found was from Michael Wallner saying that he was going to look into the issue:

http://permalink.gmane.org/gmane.comp.php.devel/82473

Well, the issue is still there, so the bug is not properly solved, IMO.

Below is the content of ext/standard/tests/serialize/bug64146.diff on my 32-bit system after the failure of the test:
===
$ cat ext/standard/tests/serialize/bug64146.diff003+ 
004+ Notice: Trying to get property of non-object in /usr/src/php-5.5.7/ext/standard/tests/serialize/bug64146.php on line 49
005+ 
003- 2
$ 
===

Fixed in 5.5.5-5.7 http://3v4l.org/DR8T3

Still happens for me in latest 5.5 on 32-bit. I think the problem is as follows:

When serializing the value given by clone in the first B object, it is remembered in the var_hash. However, it is then immediately destroyed. When it comes to serialize the other value in the second B object, the new clone is created. By chance, it may happen that this clone is located in the same memory address and has the same object ID as the previous clone. Thus, since the common hash is used, for the system it is indistinguishable from the clone created when serializing the previous B object. Thus, it is recorded as reference (r). This is wrong (since it essentially says both B objects refer to the same object, while they are not) but this is only half of the bug. 

unserialize() fails for a different reason. The reason is that when trying to parse r:4; it should replace current return value with pointer to the element 4 (which is previous B object) but it can not since it is given only return_value and not return_value_ptr. I.e., it does the replacement but this replacement does nothing, since unserialize() expects by-value return. It can be fixed, but the result will still not be right - in that case, the return would look as if both B classes refer to the same value. 

I'm not sure how to fix it properly, as the engine in this case has no good way to distinguish between the two clones short of retaining each object it serializes, which may make serialization significantly more expensive.

Those most recent commit links seem broken.

For future reference, this appears to be the patch that fixes:

http://git.php.net/?p=php-src.git;a=commit;h=8973390541faaadfdfc0f838421f037060188e5e

It appears that this bug is not really fixed. There are many
failing tests reported for PHP 5[1]. Apparently there are no
problems with PHP 7.

It seems to me that indeed the only way to fix this issue reliably
would be to detain the objects from being freed during the
serialization, what is done in PHP 7. However, the same technique
can't be used in PHP 5 for BC reasons.

[1] <https://qa.php.net/reports/viewreports.php?version=5.5.5&test=%2Fext%2Fstandard%2Ftests%2Fserialize%2Fbug64146.phpt>

Marking as duplicate of bug #66085. This issue is fixed in PHP 7.0.