Notice: unserialize(): Error at offset 2 of 52 bytes in C:\Inetpub\UC Pub\includes\bootstrap.inc on line 130

For me, this happened after having tried the Rep[lacement] Tags module. Somehow the module's database entries became corrupt. Several of them reported strings at a certain length and then the strings were a completely different length altogether. That caused the unserialize() function to fail and PHP issued 6 notices that kept popping up at the bottom of my screen over and over (as I learned elsewhere, you can reliably get the PHP notice if you submit the Admin>Settings page.)

A friend of mine helped me out with some debugging to try and track down the database entries that were causing the issue. To do so, we first tracked down the line in boostrap.inc that was reported in the PHP notice (in your case it seems to be line 130). In my case (and I would assume in your case), the line contained a call of unserialize(), and particularly in my case it was contained within the variable_init function. I commented out that line and replaced it with the snippet my PHP-whiz friend whipped up.

The original bootstrap.inc variable_init function:

/**
 * Load the persistent variable table.
 *
 * The variable table is composed of values that have been saved in the table
 * with variable_set() as well as those explicitly specified in the configuration
 * file.
 */
function variable_init($conf = array()) {
  // NOTE: caching the variables improves performance with 20% when serving cached pages.
  if ($cached = cache_get('variables')) {
    $variables = unserialize($cached->data);
  }
  else {
    $result = db_query('SELECT * FROM {variable}');
    while ($variable = db_fetch_object($result)) {
      $variables[$variable->name] = unserialize($variable->value);
    }
    cache_set('variables', serialize($variables));
  }

  foreach ($conf as $name => $value) {
    $variables[$name] = $value;
  }

  return $variables;
} 

And the variable_init function after:

/**
 * Load the persistent variable table.
 *
 * The variable table is composed of values that have been saved in the table
 * with variable_set() as well as those explicitly specified in the configuration
 * file.
 */
function variable_init($conf = array()) {
  // NOTE: caching the variables improves performance with 20% when serving cached pages.
  if ($cached = cache_get('variables')) {
    $variables = unserialize($cached->data);
  }
  else {
    $result = db_query('SELECT * FROM {variable}');
    while ($variable = db_fetch_object($result)) {
      $value = unserialize($variable->value);
      if($variable->value != serialize(FALSE) && $variable->value != serialize(0) && 
      $variable->value != serialize("0") && $variable->value != serialize("") && 
      $variable->value != serialize(array()) && $value == FALSE) {
        echo($variable->name . " =&gt; " . $variable->value . "<br />\n");
      }
      $variables[$variable->name] = $value;
    }
    cache_set('variables', serialize($variables));
  }

  foreach ($conf as $name => $value) {
    $variables[$name] = $value;
  }

  return $variables;
} 

This allowed me to see what database variable was incorrect by dumping a list of variables that did not meet certain conditions when creating the page. These conditions may or may not be the same for you, I guess, so there may be some more work involved here. Anyway, I discovered the exact reason why I had 6 or so PHP Notices popping up at the bottom of random pages: there were 6 database entries that were bad. I loaded up phpMyAdmin and surgically removed them. (Be careful, of course.) In my case they were leftover reptag entries. (I had previously removed the module, having once suspected it as the culprit. I neglected, of course, to remove its database entries.) Anyway, once I got rid of the offenders, I restored bootstrap.inc to its original state, and all was well!

Of course, I was lucky.. my offenders were useless database entries I could simply remove; I figure it could have been worse.

It's not much, but it's a start.

I get these periodically too, and just figured out what for me is a better way to debug them. The other posters on this thread advice making changes to bootstrap.inc, but any changes to echo out the variable names causes those to be echoed out on every page load - something that isn't tolerable on a production server.

My solution is as follows:

use your mysql command line client (or, I suppose, something like phpmyadmin) to issue the folllowing bit of SQL against your drupal database:

select name,length(value), value from variable where length(value) = <the last byte value on the error message>;

so, for the poster above:

select name, length(value), value from variable where length(value) = "52";

This will show you the variable name and value that is being handed to the unserialize() function, and you can start more in-depth debugging from there. Of course, if you have more than one variable with a value of length "52" then you'll have more than one thing to look at.

this is pretty rediculous, but just in case someone has been as rediculous as me ...

I developed my site on localhost.

Therefore my temp dir variable (file_directory_temp) was set to
When I went ahead and put the site live I copied over the database and went into the variables database hardcore to change the variable to ...
I forgot to change the s value "36" to match the length of the new temp-dir string ...
So it had to be

I'm sure there are other ways to set this variable to the right value automatically (by running update.php maybe?) , but haven't found them yet

I used the above mentioned SQL query method to look up (directly in the database) what variables were causing the problems first.

My issue was related to UTF-8. String shorter - character-wise (because contained UTF-8) but unserialized expecting longer one.

Solution:

function mb_unserialize($serial_str) {
$out = preg_replace('!s:(\d+):"(.*?)";!se', "'s:'.strlen('$2').':\"$2\";'", $serial_str );
return unserialize($out);
}

and

$variables[$variable->name] = mb_unserialize($variable->value);

instead of

$variables[$variable->name] = unserialize($variable->value);

This is still a helpful troubleshooting tip 5 years later - thanks! One thing I noticed is that this code will echo the variable if it is set to NULL. It doesn't mean that the variable is hitting the unserialize() error.

Maybe add in an extra condition to the check:


$variable->value != serialize(NULL) &&