php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #46882 Serialize / Unserialize misbehaviour under OS with different bit numbers
Submitted: 2008-12-16 14:54 UTC Modified: 2009-03-17 22:06 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: max at phoenixweb dot it Assigned: mattwil (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 5.2.8 OS: Centos 5.2 x86 64bit
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: max at phoenixweb dot it
New email:
PHP Version: OS:

 

 [2008-12-16 14:54 UTC] max at phoenixweb dot it 
Description:
------------
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)
 

s:3:"mem";a:2:{s:6:"memory";a:5:{s:5:"total";i:4139868160;s:4:"free";i:1306845184;s:7:"buffers";i:74797056;s:6:"cached";i:2103566336;s:4:"used";i:2833022976;}s:4:"swap";a:3:{s:5:"total";i:8389742592;s:4:"free";i:8389742592;s:4:"used";i:0;}}

During the UNSERIALIZE function on the 32bit system the bitcode is lost and the number became negative.

Reproduce code:
---------------
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.

Expected result:
----------------
I expected that the object could be pass throug PHP servers indipendently from the OS bit system.

Actual result:
--------------
The actual result is a serialized string not indipendent from OS, i think i'll use JSON functions instead of serialize / unserialize.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-16 15:03 UTC] max at phoenixweb dot it 
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.

:(
 [2008-12-16 15:13 UTC] crrodriguez at opensuse dot org 
This behavior is expected, but the documentation of serialize() does not mention it, this is a documentation problem.
 [2008-12-16 15:26 UTC] max at phoenixweb dot it 
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.
 [2008-12-16 17:57 UTC] jani@php.net 
serialize() is not meant for passing data between systems. There are other methods for that. (wddx for example)
 [2008-12-16 18:13 UTC] max at phoenixweb dot it 
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.
 [2008-12-16 18:25 UTC] mattwil@php.net 
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:
http://realplain.com/php/bug46882.diff
http://realplain.com/php/bug46882_5_3.diff
http://realplain.com/php/bug46882_5_2.diff

Commit?
 [2008-12-17 09:19 UTC] bjori@php.net 
There is nothing wrong with passing serialize()d strings between systems.
Reclassifying as a bug a again.
 [2009-03-17 22:06 UTC] mattwil@php.net 
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
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Nov 23 08:01:28 2024 UTC