Problems with unserializing data (arrays)

molesquirrel

So, I commonly use serialize() and unserialize() to enter and extract arrays from my db. I've never had any problems entering the data, but just recently, strange results have been occuring when I try to unserialize the serialized array from the db. First off, here is the array in serialized form:

a:1:{i:1089154742;a:3:{i:0;s:6:"Blaser";i:1;s:14:"ImAWannabeOgre";i:2;s:410:"Our thieves assassinated 180 enemy wizards!
Our thieves have returned with 78,835gc.
Our thieves were able to steal 45,150 runes.
Our thieves were able to steal 35,685 runes.
Our thieves were able to steal 28,203 runes
Our thieves were able to steal 22,291 runes.
Our thieves were able to steal 17,618 runes.
Our thieves were able to steal 13,925 runes.
We have converted 553 enemy soldiers to our army.";}}

Now, here is the error I get:

Notice: unserialize(): Error at offset 489 of 499 bytes in c:\root\web\utopiapimp\array.php on line 14

all that happens on that line is

PHP:
echo  htmlentities(print_r(unserialize($_POST['data']),T
rue));

where $_POST['data'] is the serialized array listed above.

Normally, I would understand the above error, but I can't see what error in the serialized text it's referring to. since no manipulation occurs on the text between entering and retrieving it from the database (other than addslashes() on entry to create a valid mysql statement).

I can't really figure out where the error in my code is, but I figured I might get a hint if I can figure out what error the Notice is referring to in the serialized text. In other words: I know what the error means in general terms, I just don't know what's at this specific byte that is making it complain.

Thanks in advance!

tsinka

Hi,

the problem is that the serialized data is corrupt. If you change the serialized array a little bit the error should disappear.

Change 410 in the serialized array string to 411 and it works (at least when I tested that). Maybe a bug in serialize or something like that. Which PHP version do you use ?

Another value than 411 might be neccessary since I don't know how my copy'n'paste action affected the contents of the serialized string.

The number (410 in this case) should mach the character count of the string which seems to be 411 in this case.

How does the query look like that inserts the serialized array data into the table.

(Besides that, I wonder if there is a solution without the need to POST the serialized data)

Thomas

molesquirrel

Thanks for the detailed response. It was exactly what I was looking for.

First, a clarification: the original script(s) which stored/retrieved this serialized data do not pass the data around via $_POST. I made a smaller script that attempted to unserialize whatever was dumped into a form for ease of analyzing database data.

Very interesting with the wrong length on the string inside of the serialized array. I checked with 411 and it did appear to look fine. I went ahead and pulled out another chunk of serialized data which was suffering from similiar problems and found out that two strings within it had been given wrong strlen values, but this time they were off by 8. I...can't see immediately any specific characters in these arrays which might be getting 'passed' up by the str counter (since the value entered into the serialized text is always less than what the actual value is), but I'll try to run a bit more analysis on it.

If I can, I'm going to try and recreate some code that produces the same results, but I'm somewhat doubtful about that, as the array was created over a number of different scripts and script executions to arrive at the state that it was in.

Again, thanks for the help, and I'll try and post updates if I figure out anything else (I went ahead and corected the data in the database, but I'd like to see why that happened to prevent further issues).

edit: an analysis of another piece of text that was throwing the same error revealed that it was a)9 chars short in it's count of the string's length, and b)there were exactly 9 (each) of the following present in the string: newline (10 ascii) and carriage return (13 ascii). At least this feels like we're getting somewhere. I'll see if I can dig in further and figure out how to reproduce it.