ID: 17490
User updated by: weyrick@roadsend.com
Reported By: weyrick@roadsend.com
Status: Open
Bug Type: Session related
Operating System: linux rh7.2
PHP Version: 4.2.1
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2002-08-22 14:17:58] dougqh@incogen.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-08-22 00:38:47] mark.hershenson@aresdirect.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-21 21:08:11] 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-21 14:53:02] mark.hershenson@aresdirect.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-07-29 10:23:01] weyrick@roadsend.com
reopen
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17490
--
Edit this bug report at http://bugs.php.net/?id=17490&edit=1