Help!! Still having problems with unserialize!

[kael.shipman]

Hi everyone,

 

I posted a topic here a week ago and never got a reply. I've been working on it for a while, too, and haven't been able to figure it out on my own. If anyone has any ideas, I really need to hear them! Here's the link to the topic: http://www.phpfreaks.com/forums/index.php/topic,164402.0.html.

 

Also, I've eliminated the database as the source of the problem and traced it directly back to unserialize by storing the object in a session variable across pageloads rather than in the database. It works until the object gets to a certain size, then craps out with the same symptoms: Download dialog box appears instead of page. I still blame it on unserialize because PHP serializes/unserialize session variables across pageloads, supposedly using the public functions for those purposes.

 

I really need to get this figured out, so if anyone has any suggestions, please let me know.

 

Thanks,

Kael

[toplay]

It's hard for members to help when you don't supply any code.

 

I would not use 55K worth of data in a session, use a database instead.

 

In PHP 5, serialize and unserialize happens automatically, but if you're using classes, they must be first defined prior to issuing a session_start().

 

Also, are you using load balance servers? one request may go to one server, while the next page may go to the other server and session data will get lost/dropped.

 

Output stuff sent where it accidentally the forces browser to issue a save as dialog could mean the headers being sent are wrong.

 

We can't help much without seeing code.

[kael.shipman]

Thanks for the reply.

 

I know it's hard to help without code in many cases, but the code that's causing the problem here is seriously just

$chkCmd = @mysql_fetch_row(@mysql_query("select cmd from commands where prsID = $prsID"));
//var_dump($chkCmd); die();
if ($chkCmd) $cmd = unserialize($chkCmd[0]);
else $cmd = new command('[Command Name]');

 

I've commented out absolutely everything else, as well as trying several different comment debugging approaches. I put that comment (var_dump($chkCmd); die(); ) in there to show that I've also checked that the serialized string is not only present, but is actually valid (I found the closing curly brace for the object at the end). The problem here is entirely with the unserialize function, but I'm just wondering if there are limitations on the function that I didn't know about or if there are configuration settings or anything that would cause it to show or prevent it from showing the download dialog instead of loading the page.

 

For a little background, I was using the database initially, but tried putting it in a session for debugging purposes. While it was there, I did include the class definitions before the session was initialized. The same problem is experienced regardless of whether the string comes from the session variable or from the database. As I'm playing with it, I'm leaning more and more toward it just being a size limitation with the unserialize() function. The function works when I use it between the first few pages, but it breaks as the object gets bigger and bigger.

 

Thanks again for any help,

Kael

[toplay]

I recommend that you never get in the habit of coding queries in that way...never double embed like that. Separate each one out and while at least debugging, remove the "@" since it suppresses any errors. Display any possible errors returned by MySQL.

 

Yes, you could be right about hitting upon a size limitation, however, you can increase the memory allocated to the script and I bet that will help. See:

 

http://us3.php.net/manual/en/ini.core.php

http://us3.php.net/manual/en/function.ini-set.php

 

 

Also, you could try to compress the string...i.e. gzcompress(serialize($cmd)):

 

http://us3.php.net/manual/en/function.gzcompress.php

 

http://us3.php.net/manual/en/function.gzuncompress.php

 

Also if the command() class requires any other classes, then those classes must also be defined/included in the script first.

 

[kael.shipman]

Just curious... do you have compelling reasons not to embed functions like that? I figure if the mysql_query() fails (with an actual PHP error), then the extension is bad and nothing in the script is gonna work anyway. You have to fix the build then, so there's real script debugging. If it's the query itself that's bad, I'll still know what information's not being gathered (and therefore which query isn't returning expected results) and all I have to do is add echo mysql_error($cnx); below it and it'll spit out my error. I've been doing this with no negative results for 2 years now.... What's so bad about it?

 

-kael