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

go to bug id or search bugs for

Bug #17490 serialize() generates a string that unserialize() can't handle
Submitted: 2002-05-28 15:41 UTC Modified: 2002-10-26 01:00 UTC
Votes:13
Avg. Score:4.5 ± 1.1
Reproduced:11 of 11 (100.0%)
Same Version:6 (54.5%)
Same OS:7 (63.6%)
From: weyrick at roadsend dot com Assigned:
Status: No Feedback Package: Strings related
PHP Version: 4.2.1 OS: linux rh7.2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: weyrick at roadsend dot com
New email:
PHP Version: OS:

 

 [2002-05-28 15:41 UTC] weyrick at roadsend dot com 
this bug is filed under "Session related", but is not specific to the session system, but rather the serialize/unserialize mechanism. I'm not using the php session code to generate the bug.

compile info is ./configure --with-apxs --with-mysql on a linux rh 7.2 machine. tested with PHP 4.2.1 and 4.1.1

problem: while attempting to serialize a complex structure, PHP generates a string that unserialize is not able to handle. the exact error message is:

unserialize() failed at offset 1016 of 5327 bytes

unserialize() fails even when the previous statement serializes it, ie:

$serVal = serialize($data);
$unSerVal = unserialize($serVal);

so the data is not mucked with between serializing and unserializing.

the exact data it's unserializing is included -- as you can see it's a pretty complex data structure made up of just about every php type there is. from just a glace, i don't see a problem with the actual byte it's failing on.

please email me for more information on reproducing this.

--- begin data ---
a:8:{s:10:"__SM_mpv__";s:0:"";s:11:"connections";a:1:{s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";a:4:{s:6:"dbType";s:5:"mysql";s:8:"userName";s:5:"xxxxx";s:8:"passWord";s:7:"xxxxxxx";s:8:"hostName";s:7:"lazarus";}}s:6:"curCon";a:4:{s:3:"cID";s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";s:3:"cDB";s:6:"reCIMS";s:3:"cTB";s:7:"members";s:3:"cVF";s:8:"userName";}s:4:"cols";a:1:{s:56:"ec240bd77ee9043c536a9c9f1d1efeb0|reCIMS|members|userName";a:8:{s:6:"idxNum";O:11:"mycolumndef":22:{s:6:"target";s:46:"/sfbuilder/home/index.php?newColumnName=idxNum";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:0;s:6:"dbHook";s:7:"maxSize";i:10;s:4:"name";s:6:"idxNum";s:10:"needQuotes";b:0;s:10:"prettyName";s:7:"Idx Num";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:10;s:9:"tableName";s:7:"members";s:10:"columnType";s:3:"int";}s:3:"uID";O:11:"mycolumndef":22:{s:6:"target";s:43:"/sfbuilder/home/index.php?newColumnName=uID";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:32;s:4:"name";s:3:"uID";s:10:"needQuotes";b:0;s:10:"prettyName";s:4:"U ID";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"userName";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=userName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"userName";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"User Name";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"passWord";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=passWord";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"passWord";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"Pass Word";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:12:"emailAddress";O:11:"mycolumndef":22:{s:6:"target";s:52:"/sfbuilder/home/index.php?newColumnName=emailAddress";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:60;s:4:"name";s:12:"emailAddress";s:10:"needQuotes";b:0;s:10:"prettyName";s:13:"Email Address";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:9:"firstName";O:11:"mycolumndef":22:{s:6:"target";s:49:"/sfbuilder/home/index.php?newColumnName=firstName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:50;s:4:"name";s:9:"firstName";s:10:"needQuotes";b:0;s:10:"prettyName";s:10:"First Name";s:8:"required";b:0;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"lastName";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=lastName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:50;s:4:"name";s:8:"lastName";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"Last Name";s:8:"required";b:0;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:11:"dateCreated";O:11:"mycolumndef":22:{s:6:"target";s:51:"/sfbuilder/home/index.php?newColumnName=dateCreated";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:19;s:4:"name";s:11:"dateCreated";s:10:"needQuotes";b:0;s:10:"prettyName";s:12:"Date Created";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"date";s:4:"size";i:19;s:9:"tableName";s:7:"members";s:10:"columnType";s:8:"datetime";}}}s:6:"curKey";s:56:"ec240bd77ee9043c536a9c9f1d1efeb0|reCIMS|members|userName";s:8:"tempDirs";s:0:"";s:13:"smartFormDirs";s:0:"";s:8:"SM_debug";s:0:"";}
--- end data ---

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-21 14:53 UTC] mark dot hershenson at aresdirect dot com 
[It would seem that this and bug #18404 are related, in case anyone wanted to combine them.]

I am currently debugging an issue which I am finding hard to find which centers on trying to serialize and deserialize very complex objects which, when serialized, are around 580k in size. It's all part of a custom session handler.

However, I have run into this particular problem myself, and it is causing me fits.

Even if I break some of the items into their component parts, the serialization will fail, but it would appear it is the complexity of the objects, not the size of the string which seems to determine failure.

To get around the issue, I have had to write a custom serializer, but am now running into a PHP userland limitation of not being able to cast a stdClass to the desired class without having to call the constructor of the destination class without knowing the variables to pass to it.

Considering the ease of use of sessions and the serialize/deserialize functions, shouldn't this be more highly assigned in the outstanding bug database?

I can volunteer whatever time is necessary to get this fixed, but will definitely need help from those who know how the engine works better than I.

=======

My configure and system info:

 './configure' '--with-mysql=/usr/local/mysql' '--enable-track-vars' '--enable-inline-optimizations' '--enable-wddx' '--with-dom=/usr/local/libxml' '--with-dom-xslt=/usr/local/libxslt' '--with-dom-exslt=/usr/local/libxslt' '--with-zlib-dir' '--with-apxs=/opt/apache13/sbin/apxs' '--quiet'

RedHat 7.3 / Linux aries.aresdirect.com 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

[markhers@aries ~]$ uname -a
Linux aries.aresdirect.com 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown

[markhers@aries ~]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)

From phpinfo():

API Versions:
PHP:				20020307
PHP Extension:		20020429
Zend Extension:		20020731

Server sig:

	Apache/1.3.26 (Unix) PHP/4.3.0-dev
	
----------------

  -- mjh
 [2002-08-21 21:08 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-08-22 00:38 UTC] mark dot hershenson at aresdirect dot com 
I just downloaded, compiled, and restarted Apache 1.3.26 
with the latest php4-latest.tar.gz and no change. In fact, 
it would seem that there is now a regression - a 10 element 
array with objects in each index now won't even serialize.

In order not to clutter the bug DB, the following link 
should help you to see the issue and data structures at 
play here:

     http://www.green-ant.com/serialize-issues.php

I included the Debug::Debug() function, but not the base 
classes for NDA reasons. Since it's the data that gets 
serialized, not the functions, that shouldn't be a problem. 
;)
 [2002-08-22 14:17 UTC] dougqh at incogen dot com 
As others have said, the problem seems linked to the complexity of the variable being serialized and not strictly the size of the result string.

Of note, the WDDX serializer serialized and unserialized my object array without any problems, but its lack of reference support may account for that.

I actually needed references preserved, so for now I am using a combination of pre-serialization and post-unserialization processing in combination with WDDX as a work around.
 [2002-09-09 13:09 UTC] weyrick at roadsend dot com 
i'm not sure about the others who were having similiar problems, but the problem i was having has been solved.

it turned out to be a misuse of the __sleep() method in my base object. i mistakenly thought the method should have been unsetting variables not to be serialized, when in fact it needed to return an array of variables TO serialize. once this mistake was caught and fixed, serialization of my objects started working.

it would still seem to be a bug in PHP, however, to have the actual unserialize call fail directly after a serialize call. this should give a good starting point for the developers to look at, and others who were having a similiar problem can check their code.
 [2002-09-16 09:28 UTC] dougqh at incogen dot com 
My problem is not improperly using __sleep.

Referencing complexity definitely seems to be part of the problem.  I am serializing multiple groups of objects for different purposes.  Some of my object structures have relatively simple referencing complexity, and I can get away with using the standard serializer on those objects.  

Others are far more free form and complicated, and I cannot safely use the standard serializer on those objects.

At one point, I created a failure in my "simple" objects (the ones using the standard serializer) when I tried to add an associative array of numeric arrays of objects to the top-level object being serialized.  The objects in the numeric array pointed back to the top-level object containing the associative array.

Old referencing structure ...
object A -member is-> associative array -elements are-> arrays -elements are-> objects -points to-> object A

I resolved this problem by removing the associative array from the equation and creating dynamically named variables to directly contain the object arrays.

New referencing structure ...
object A -members are-> arrays -elements are-> objects 
-points to-> object A
 [2002-09-25 06:34 UTC] sas@php.net 
Not session related, reclassified.
 [2002-10-10 22:54 UTC] iliaa@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

This bug may be related to locale issues that were addressed in the latest CVS.
 [2002-10-16 12:55 UTC] dougqh at incogen dot com 
I just noticed that problem I am describing with serializing arrays/objects looks very similar to bug 14293.
http://bugs.php.net/bug.php?id=14293
 [2002-10-26 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC