Posted by kahenya on July 1, 2010 at 5:47pm
8 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | variable |
Issue Summary
Hi
I migrated and launched my new site and this error is now appearing every other minute on top. I'm not quite sure where to start. Anyone seen this before or have any experience with something like this? I've already truncated all the mysql cache tables and that did not help. Please help.
Thanks.
Kahenya
Notice: unserialize() [function.unserialize]: Error at offset 26 of 405 bytes in /home/******/public_html/*******/includes/bootstrap.inc on line 551
Comments
#1
This indicates you have an invalid value in your variable table. Have you changed any of those values?
#2
I am having a similar issue
notice: unserialize() [function.unserialize]: Error at offset 42 of 374 bytes in unserialize() (line 637 of /public_html/includes/menu.inc).
code is as follows
<?php/**
* This function is similar to _menu_translate() but does link-specific
* preparation such as always calling to_arg functions.
*
* @param $item
* A menu link
* @return
* Returns the map of path arguments with objects loaded as defined in the
* $item['load_functions']:
* - $item['access'] becomes TRUE if the item is accessible, FALSE otherwise.
* - $item['href'] is generated from link_path, possibly by to_arg functions.
* - $item['title'] is generated from link_title, and may be localized.
* - $item['options'] is unserialized; it is also changed within the call
* here to $item['localized_options'] by _menu_item_localize().
*/
function _menu_link_translate(&$item) {
(line 637) $item['options'] = unserialize($item['options']);
?>
To me this would tell me that there is an error somewhere with one of the menu links. This is where I get lost.
The problem is that I have not personally changed any of the db values but I do not know how to go about finding or correcting the problem with the db.
Any help would be appreciated.
#3
I'm hitting this on 7.0-rc4. I can't reliably reproduce it on every page, but it *seems* to happen when I view a page for the first time (in a new session) when logged in:
Notice: unserialize() [function.unserialize]: Error at offset 74 of 75 bytes in variable_initialize() (line 749 of /srv/www/<sitename>/includes/bootstrap.inc).My display_errors in php.ini is configured to NOT show notices and the "Error messages to display" setting in Logging and Errors is set to 'None'. between those two, I don't know why Drupal thinks it's a good idea to show errors anyway.
I've just upgraded a 6.20 to 7.0-rc4 and after some digging I found that the Notices were caused by a few settings left in the variable table by contrib modules that I had uninstalled. So basically, mine was caused by contrib modules that didn't properly clean up after themselves. Yours like has the same cause.
To find out which variables were my problem, I added some debug code in place of the call to variables = array_map('unserialize', ...) to instead loop through the list of variables, unserialize each one and then check whether the call returned a boolean FALSE. If so, and the variable was NOT maintenance_mode you've found your culprit(s).
#4
The fix, effectively is: #145164: DX: Use hook_variable_info to declare variables and defaults :-) But until that time I think your only recourse is to find the offending value in the variables table and remove it.
#5
Running into same problem. Added this feature request: #1018146: unserialize error message should be more helpful.
How do we tell which variable is the issue? My case is an upgraded D6 -> D7 database.
#6
You can try this to debug it. I however don't know if it is possible that FALSE is a valid value in this case, but shouldn't:
After the line with the error.
<?phpif ($item['options'] === FALSE) {
debug($item);
}
?>
Note that this is only debug code, it should print the whole menu item which is borked.
#7
Yes, FALSE is a valid return value for such settings as
maintenance_mode. I was planning to write a small module that would provide this debug feature and optionally a delete link to remove a value that doesn't evaluate properly.edit
And that module is now done. Grab it from http://drupal.org/project/variablecheck and install as per normal. It'll add an entry on the Reports page and it also runs in the Status Report. It doesn't generate false positives on a boolean FALSE :-)
#8
I got lucky. My error was in a 333 byte variable, so I easily spotted it in phpmyadmin. Turns out it was some variable for a theme I stopped using.
#9
I had the same issue after moving modules from '/sites/all/modules/' to 'sites/all/modules/contrib/'. In my case the culprit was 'PHPMailer' -- see issue #1081494: Variablecheck: invalid variable in 'smtp_library'.
Thanks for the byte hint, @Aren Cambre! That's a good one :)
Considering this kind of technical behaviour, that variables are left in the table (despite uninstalling/reinstalling a particular module; 'PHPMailer' above for instance): Could anyone file an issue in the right place? This must be a core problem -- I don't think this should be the case. And ... it reminds me a bit on #1013666: Renaming a block display machine name leaves stale records in the block table !
#10
... oh, I've just seen 'Variables deleted automatically when the module is uninstalled' on http://drupal.org/project/variable !
#11
Thanks cafuego.
I think variablecheck should be available in core.
#12
Each module is responsible for deleting their own variables. I suggest you open an issue for that module.
Drupal core currently does not keep track of which variable is used by which module and can therefore not remove it automatically. I personally tried to change this in 7.x but the current system simply doesn't work for doing that.
#13
Drupal core can make the error less cryptic. Maybe tell us which variable is the problem instead of making us do a wild goose chase?
#14
The actual error message originates from PHP. Because Drupal calls unserialize() in so many different places (76 in current 7.x), I think only practical way would be to introduce a drupal_unserialize wrapper that traps and logs errors. Such a change would have to be D8.
#15
And I'm not sure that is a good idea. As you said, unserialized is used *a lot*, and adding yet another wrapper function that would have to check the return value and act accordingly would make it even slower than it already is.
#16
I believe there's a plan for a variables API in D8. If a module can only write/read variables it has registered, Drupal can easily remove just those when the module is uninstalled. Not to mention that there's a chance D8 will throw away the variables table altogether.
Annoying though this warning is, it'll only happen with D5 (or older) variables. D6 already stores them serialized. That means the warning won't re-occur if new modules you install now don't clean up their mess (though some will undoubtedly leave cruft). Still, the code in this module would basically run just once, so I don't think adding it to core would make sense (Let's say install.php is a special case ;-)