go to bug id or search bugs for
The problem is easy.
I use SERIALIZE - UNSERIALIZE to pass complex PHP objects between server e store it on remote.
However the SERIALIZE - UNSERIALIZE process fail while this happens between a 64bit OS and a 32bit OS, due to a missbehaviour in the number rappresentation (int).
For the 64bit the (INT) is the correct data type for the number: 4139868160 while for a 32bit system that numbero can handled only by a (DOUBLE)
During the UNSERIALIZE function on the 32bit system the bitcode is lost and the number became negative.
serialize this object on different OS:
[mem] => Array
[memory] => Array
[total] => 4139868160
[free] => 1331732480
[buffers] => 68988928
[cached] => 2102939648
[used] => 2808135680
[swap] => Array
[total] => 8389742592
[free] => 8389742592
[used] => 0
you'll get different SERIALIZED string that are not OS indipendent.
I expected that the object could be pass throug PHP servers indipendently from the OS bit system.
The actual result is a serialized string not indipendent from OS, i think i'll use JSON functions instead of serialize / unserialize.
Add a Patch
Add a Pull Request
As I can see from the Function Manual, JSON is not a possible alternative due to his limitation in nested elements.
So... i have to wait that somebody fix this one.
This behavior is expected, but the documentation of serialize() does not mention it, this is a documentation problem.
But this is a problem.
Serialize is needed to store PHP object as a string. Is this correct?
There are a lot of possibility of needed an object as a string, like complex data storage, and pass data from a server to another server.
If the data is not unserializable from a different server, it's completely useless.
When i'll upgrade my server to 12Gb of RAM (needing a 64bit OS), i'll have to trash all the data stored with SERIALIZE on my MySqls?
I don't think that the correct way is just to add a comment to the current documentation.
I think this should be consider a bug, cause SERIALIZE / UNSERIALIZE is used to storage data and pass it across servers, so must be compliant with the problems of differents OS system behaviours.
serialize() is not meant for passing data between systems. There are other methods for that. (wddx for example)
WDDX is the best solutions to speak across different programming languages.
But we are talking about 2 system serving PHP (not one PHP and another JAVA)!
That should speak using PHP serialization of PHP objects.
PHP is compatible with differents PHP server by using WDDX but cannot communicate with others PHP server by using its native way to serialize (this seems to me a little bit silly).
But i won't ask for a personal solution just for my problem, consider the bug from another point of view: what about an upgrade of the current system to a system that run more than 4Gb of RAM.
Should I trash all the data of my Sql stored as a SERIALIZED object????
I think this is silly.
By the way i'm fixing this by forcing casting floats for every int on the 64bit before serialize.
I'd agree that it's a bug... And I'm surprised *I* didn't catch this one back when I was looking into other number-related stuff. :-)
Patches for all 3 branches:
There is nothing wrong with passing serialize()d strings between systems.
Reclassifying as a bug a again.
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.