php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: marie_bw at web dot de
New email:
PHP Version: OS:

 

 [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-2020 The PHP Group
All rights reserved.
Last updated: Wed Oct 28 18:01:24 2020 UTC