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

go to bug id or search bugs for

Bug #31970 serialized object can't be unserialized
Submitted: 2005-02-14 14:39 UTC Modified: 2005-02-14 20:15 UTC
From: marie_bw at web dot de Assigned:
Status: Not a bug Package: *Programming Data Structures
PHP Version: 4.3.10 OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
30 - 13 = ?
Subscribe to this entry?

 
 [2005-02-14 14:39 UTC] marie_bw at web dot de 
Description:
------------
On complex objects the serialize() function produced
output in which string members of an object would be
stored together with a wrong string size, e.g. the
string length ist 60 bytes but serialize() notes only 58.

The data can't be processed by unserialize().

This would only happen if characters like single or
double quote were present in the string (this string
came from HTTP_POST_VAR). But also a substitution
of quotation character by '"' or 'x' would not
bother serialize() to produce the right output.

This is not reproducible with small objects. The
objects in question where rather complex and came
from the application "phpopenchat".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-14 18:51 UTC] marie_bw at web dot de 
After heavy investigation I suspect that
the problems originate from the Adodb mysql
driver which is bundled with Phpopenchat and
another problem in this application.

Escape characters are erroneously stripped
from already serialized strings in two
different places (one of them in the 
approvement cycle of moderated chat channels)

It basically can be circumvented by disabling
"magic_quotes_gpc" but only by chance.

I reset the status of this report to "bogus"
as this might not touch PHP in any way.
 [2005-02-14 20:15 UTC] helly@php.net 
In version prior to 4.3.10 there was such an error. So if the input is from such a version the problem is solved now. Unless you have a reproducing script that generates serialized data that cannot be unserialized using current version this report should stay bogus.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 03:01:27 2024 UTC