PHP :: Request #46882 :: Serialize / Unserialize misbehaviour under OS with different bit numbers

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:

CVE-ID:

None

View Developer Edit

[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.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Tue Dec 03 17:01:29 2024 UTC