2

I am getting this error after migrating the site to a new server:

Notice: unserialize() [function.unserialize]: Error at offset 2 of 23 bytes in includes/bootstrap.inc on line 478

I'm sure somewhere a setting has been corrupted; however, the site does appear to be functioning correctly. This error does return inconsistently, for anonymous users, so I do need to take care of it.
The error does not occur on the old server.

I have full control of the server, both the new and the old are Amazon EC2 VMs. The only major difference in the infrastructure is that the old server used a MySQL DB in the same VM, while the new server is using a MySQL Server in RBS.

I've read somewhere that this issue could be caused by the SQL export/import process, and something regarding UTF8. I wasn't able to garner anything I could mold into instructions to follow, but I have a feeling that's a path I need to take; I'm not really sure where to start.

5

The problem might be the error handling settings have changed on the new server. You probably have a corrupt variable in the variable table that can't be unsterilized. Try using the variable check module.

  • That's definitely easier than my approach :) – mikl Jun 21 '11 at 10:44
  • Wow good call. PHP Debug was turned on by an administrator for a separate issue. Turning this off solved the problem :) Thanks a lot! – DanH Jun 21 '11 at 11:06
  • 1
    If you just did a display_errors = Off then you are just hiding the problem and not solving it. – mpdonadio Jun 21 '11 at 12:44
3

This is rather difficult to debug, but you might edit includes/bootstrap.inc where the unserialising happens – this is from the variable_init() function, where I assume the error occurs.

The original code looks like this.

while ($variable = db_fetch_object($result)) {
  $variables[$variable->name] = unserialize($variable->value);
}

Try altering it to something like this:

while ($variable = db_fetch_object($result)) {
  $variables[$variable->name] = unserialize($variable->value);

  if (!$variables[$variable->name]) {
    drupal_set_message('Possible error while decoding ' . $variable->name);
  }
}

There will be some false positives here, given that some values are actually FALSE or 0, but it should narrow the field, helping you to identify the broken variable. Then you can inspect the variables table in the database to find and fix it :)

2

I have had this happen when I migrate a database from staging to live and have to hand edit the database for paths, domain name, etc.

What is happens in the case is that the search-replace matches a string in the variables table, and alters the row. The problem is that length (the number after the s: doesn't get changes, so the unserialize fails.

If you go into the variable editor via the admin menu, you will likely see a blank entry where there was a real variable. Either update it here and save, or use a MySQL tool and fix the length in that row.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.