Potentially reappeared at T210499

I think I tracked it down: Zend PHP and HHVM behave differently with respect to the Serializable interface and multiple instances of the same object, as shown by https://3v4l.org/J6g8e.

There are three ways serialization works in PHP:

1. Basic serialization just dumps/restores all the properties of an object.
2. Using __sleep() and __wakeup(), you can exclude some properties or do other code modifications.
3. Using the Serializable interface lets you serialize to/from any arbitrary string. Often this string is created by calling serialize() recursively.

So what happens if you have an array with two objects, each of which contains the same third object?

class Foo {
    public $obj;

    public function __construct( $obj ) {
        $this->obj = $obj;
    }
}

$obj = new stdclass;

$foo1 = new Foo( $obj );
$foo2 = new Foo( $obj );

$s = serialize( array( $foo1, $foo2 ) );

$data = unserialize( $s );

With either #1 or #2, it serializes that reference to $obj as a reference (code 'r') so when things are unserialized $data[0]->obj === $data[1]->obj.

a:2:{i:0;O:3:"Foo":1:{s:3:"obj";O:8:"stdClass":0:{}}i:1;O:3:"Foo":1:{s:3:"obj";r:3;}}

Originally, with method #3, it broke the reference so $data[0]->obj and $data[1]->obj would be clones of each other but would not be ===.

a:2:{i:0;C:3:"Foo":35:{a:1:{s:3:"obj";O:8:"stdClass":0:{}}}i:1;C:3:"Foo":35:{a:1:{s:3:"obj";O:8:"stdClass":0:{}}}}

It seems that was reported as PHP bug 36424. The issue was eventually fixed in PHP 5.4.0 by making recursive calls to serialize() and unserialize() share state.

a:2:{i:0;C:3:"Foo":35:{a:1:{s:3:"obj";O:8:"stdClass":0:{}}}i:1;C:3:"Foo":20:{a:1:{s:3:"obj";r:4;}}}

Unfortunately it seems HHVM never picked up that fix (HHVM bug 7253).

So probably what's going on here is that someone is testing PHP 7.2 (with X-Wikimedia-Debug or the like) and triggers the creation of a serialized string like "Serializable with recursive state" above. Then when an HHVM request tries to load that state, it blows up because, without having shared state from an outer call to unserialize(), it has nothing for the "r:4" to be a reference to.

A fix for the immediate problem with the sidebar cache would be to adjust Message::serialize() and Message::unserialize() to avoid including Title objects (instead it could serialize the Title as ->getPrefixedText() and unserialize with ::newFromText() or the like). But if this occurs for other cases, they might not be so easily fixed.

I filed T210528: PHP/HHVM serialization incompatibility in some situations when using Serializable to explain the issue rather than the symptom, so I'm closing this as a duplicate of that task.