It seems that serialize function has something to do with it, it gives different outputs:

Case1, output of:
serialize(unserialize(serialize($data)));
https://dl.dropboxusercontent.com/u/11435743/php/serialize_unserialize_serialize.txt

Case 2, output of:
serialize($data)
https://dl.dropboxusercontent.com/u/11435743/php/serialize.txt

I attach this example, because data corruption does seem to occur in Case 1. It seems only to occur in Case 2.

Please excuse the error in the sentence:

I attach this example, because data corruption does NOT seem to occur in Case 1. It seems only to occur in Case 2.

It turns out I simplified Case 1 too much, I attach the whole information again:
------------

It seems that serialize function has something to do with it. It returns different outputs in the following cases:

Case 1:
unserialize(serialize($data));
echo serialize($data); // output:
https://dl.dropboxusercontent.com/u/11435743/php/serialize_unserialize_serialize.txt

Case 2:
echo serialize($data); // output:
https://dl.dropboxusercontent.com/u/11435743/php/serialize.txt

Data corruption DOES NOT occur when I run unserialize on the output of Case 1.
Data corruption DOES occur when I run unserialize on the output of Case 2.

Example of the currupted outputs are attached in the original post.

To summarize: putting additional unserialize(serialize($data)); before serialize($data); seems to workaround the corruption by resulting in a different output of the second call of serialize function. This output can then be safely passed to unserialize function and the corruption does not occur.

The information in comments is irrelevant. The corruption does not occur, because the object itself changes, but it is the same with any change of it - only some combinations of values cause corruption. The difference in serialize output is related to classes serialize method which removes the "parent" field.

Regarding the original problem with unserialize corruption issue:

In this single case "Make-up & Styling" became "Make-up ' Sty ing" 
& = hex 26 became ' = hex 27 
l = hex 6c became (nul) = hex 00

The changes in characters are always different and seem random.

It is worth mentioning that the issue appears out of nowhere and can be fixed by restarting the server. It seems memory related. For this reason it is not possible to provide a bug testing snippet, because it simply won't create the same issue on another machine, although it may get it's own unique corruption on a random day.

The issue presents itself always on Apache server (various versions 2-2.4), mod_php or FCGI.

I just experienced the same issue on a totally different setup
apache + mod_php 5.5.11 + zend opcache

String "Opinion Leader des Tages"
became "Opinion Leader dfs Taes"

after unserialize.

We just had the same issue on a different server (FCGI 5.4.27)
String currupted by unserialize:
"ticketshop-promo-summer-ticket" => "ticketshop-promo.summ(NUL)r-ticket"

3 more:

"ticketshop-kilometer-bank" => "ticketshop-kilomfter-(NUL)ank"
"ticketshop-promo-spar-holiday" => "ticketshop-promo.spar(NUL)holiday"
"ticketshop-promo-weekend" => "ticketshop-promo.week(NUL)nd"

Is someone still encountering this problem in PHP >= 5.6? If so, could you please specify whether you use opcache? If you do, can you check whether you get a reproducible crash if you set opcache.protect_memory=1?

Dear Nikita,

I wish you a Happy New Year with lots of happiness and joy. 

It has been so long since the issue was reported, that we managed to implement some workarounds in the meantime and we do not encounter it anymore.
That said, if I encounter it again, I will open another issue, ok?

Thanks,
Marcin

Maybe I should add that the issue was present for sure without opcache and it was not the case of shared memory, because we could repeat it any time, on any day with the same result and same corruption.

Not sure if this is the correct issue but I came across some problem with serialize/unserialize. (php-5.6.14)

I have created a gist to reproduce it:

https://gist.github.com/laszlokorte/3948f40873346cc1fd9b8c11ab06ae04

The problem is that if an object contains a another object as child in multiple places that child does not get (un)serialized correctly. Not just that the identity of the multiple occurrences is not preserved but the object is not unserialized correctly at all. It's easier to understand by looking at gist.

@laszlokorte: That is most likely bug #66085, which is fixed in PHP 7.0 (but not 5.6).

@nikic Thanks, indeed the problem of the gist I posted is solved by php7. But in my real application I now get many "Notice: unserialize(): Error at offset 1026 of 1348 bytes" errors.

@laszlokorte, there's a mistake in your gist. Definition::unserialize should pass $data to unserialize, or use $value as a parameter. Unserializing an uninitialized variable causes the false values, and not unserializing the parameter messes up the references. See https://3v4l.org/vioIT .

@nikic, imho the cause of bug #66085 is serializing additional data during serialization. Of course this can result in similar behaviour. See https://3v4l.org/9hVS2 .

@jh1711 You re right. I fixed the bug in the gist. But mainDef is not correctly unserialized in php<7 anyway and in my real application I still get the "unserialize(): Error at offset 1026 of 1348 byte error" in a similar but more complex situation (deeper nestings, more properties, but no cycles)

@laszlokorte: In that case you're probably hit by bug #66052 (see also my comment on bug #73253).

Does this issue still happen with any of the actively supported
PHP versions[1]?

[1] <https://www.php.net/supported-versions.php>

I cannot confirm or deny, since I still stick to a workaround for this issue. I suggest to close the issue.

Okay, closing then.  Thanks for the fast reply!