php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27428 serialize brakes output for unserialize, returning garbage
Submitted: 2004-02-27 20:31 UTC Modified: 2004-03-15 08:38 UTC
Votes:2
Avg. Score:3.0 ± 2.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: black at scene-si dot org Assigned:
Status: No Feedback Package: Strings related
PHP Version: 4CVS-2004-02-27 OS: debian unstable
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: black at scene-si dot org
New email:
PHP Version: OS:

 

 [2004-02-27 20:31 UTC] black at scene-si dot org
Description:
------------
The following has been tested on:

php-4.3.2               
php-4.3.4               
php-4.3.5rc2
php-4.3.5rc3
php4-STABLE-200310032330
php4-STABLE-200402101030
php4-STABLE-200402272030

with various compile options turned on/off (oracle support & turckmmcache), always giving same result

basically with every version of this some or most serialize() calls result in an incorrectlly constructed serialized string... given i only input plaintext, the serialized string must have a length of 6+strlen(original), albeit:

["cache_data"]=> string(9277) "s:9309:"... (oops!)
["cache_data"]=> string(24259) "s:24248:"... (correct.)
["cache_data"]=> string(23850) "s:23881:"... (oops!)
["cache_data"]=> string(224081) "s:224069:"... (correct.)
["cache_data"]=> string(21055) "s:21107:"... (WTF!)
["cache_data"]=> string(19590) "s:19663:"... (wrong)
...

http://scene-si.org/test.tgz - 800kb, contains 15Mb output of the reproduce code.
http://193.77.198.80/phpinfo.php for phpinfo()

Linux dahim 2.4.23-1-686 #1 Sun Nov 30 20:51:10 EST 2003 i686 GNU/Linux (thats the server this runs on).

the funny part is, that this code (the same code to generate the entries in condor_dbcache) works also on other servers, also debian, iis, apache-win, redhat, mandrake, openbsd, freebsd.. it only fucked here..

after the serialize is done, the ONLY command it goes trough is mysql_escape_string, so there is no character or other conversions which could explain the wrong length in serialized() output

Reproduce code:
---------------
<?php
mysql_pconnect("localhost","root","");
mysql_select_db("condor");

$query = mysql_query("select * from condor_dbcache");
while ($row = mysql_fetch_assoc($query)) {
        var_dump($row);
        var_dump(unserialize($row['cache_data']));
}

// unserialize throws out crap after serialized data end

Expected result:
----------------
I dont want the "; and crap after it displayed.. but more accurately.. i want serialize to behave propperly here.

since i never had this problem, i pressume its a system dependant problem, i guess you'll want this:

Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.3 (Debian)

if you need some other application version or lib version, comment - or atleast tell on what libs this depends.

Actual result:
--------------
Content starts with ei: 's:9309:"<table wid' and ends with '<br><br>";' ... but the content length is 9277..

the content was input with serialize in the following way:

$content = serialize($content);
mysql_query("update condor_dbcache set cache_timestamp='".time()."', cache_data='".mysql_escape_string($content)."' where cache_filename='".mysql_escape_string($filename)."'");

filename beeing the correspondant key to this dbcache table.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-28 17:38 UTC] black at scene-si dot org
i've also tried using mysql_real_escape_string, but it didnt solve anything (for long anyway, the garbage output came back at the worst of moments.)

the phpinfo above is still valid - any help would be appreciated, as i really dont know what to do
 [2004-03-06 14:14 UTC] iliaa@php.net
Try to see if you can replicate the bug when turckmmcache 
is not being used. 
 [2004-03-06 15:16 UTC] black at scene-si dot org
the first thing i tried was to disable it, but nothing was changed. then i tried compiling php without oracle support, nothing. then i tried compiling latest snapshots, stable relases, release candidates, older snapshots i had lying around.. everything with the same result..

of late i made a workaround by not using the database, but i still use the serialize/unserialize functions, so it probablly has something to do with the escape string / query functions (so strings related category shouldnt apply anymore?)..

unserialize caused garbage to spew out because of the incorrect reported length from serialize, and the difference of length in the actual field.. (check description, original post), this behaviour is valid, but checks should still be made so that doesnt happen (accessing memory not used by the string that gets passed to is, bad thing).

something seriously goes wrong, either with serialize.. or mysql_escape_string (or the acctual mysql application)..

why serialize wouldnt fuck up with files is beyond me..

[anyway, as to your feedback request, i tried just about everything except compiling php in debug mode]
 [2004-03-09 12:34 UTC] iliaa@php.net
Please provide a simple script with a list of strings that 
cause the problem so that we can try to replicate and 
consequently resolve the problem. 
 [2004-03-15 08:38 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 17:01:29 2024 UTC