| Project: | Memcache API and Integration |
| Version: | 6.x-1.9 |
| Component: | memcache.inc |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Hi,
Today I updated to memcache-6.x-1.9
Since then I get the following error in my pages:
warning: Invalid argument supplied for foreach() in /var/www/html/drupal/sites/all/modules/memcache/memcache.inc on line 330.
On apache error log file I get:
[Thu May 12 11:39:36 2011] [error] [client 10.0.0.2] PHP Notice: unserialize() [function.unserialize]: Error at offset 2 of 8 bytes in /var/www/html/drupal/includes/bootstrap.inc on line 556, referer: https://www.example.com/admin/reports/memcache
[Thu May 12 11:39:36 2011] [error] [client 10.0.0.2] PHP Notice: unserialize() [function.unserialize]: Error at offset 2 of 8 bytes in /var/www/html/drupal/includes/bootstrap.inc on line 556, referer: https://www.example.com/admin/reports/memcache
Centos 5.6
php-5.1.6-27
Comments
#1
Which version of memcache did you upgrade from?
Can you dump the $wildcard_flushes array with print_r() or var_export() and paste it here?
Either of these would help to identify whether this is likely to be an issue for a lot of users, or if you got unlucky upgrading from a dev release.
Please try saving the modules page, or running drush cc all - that may reset the variable.
If neither of these work, you can just delete the variable, either
<?phpvariable_del('memcache_wildcard_flushes');
?>
Or
DELETE FROM variable WHERE name = 'memcache_wildcard_flushes'from mysql command line or phpmyadmin, then a cache clear would fix it.If you do a drush cc all / save the modules page after this, then you should be fine again.
#2
Error also occurred for me. Your suggested fix of deleting the variable and clearing the cache did the trick.
#3
Same here, using:
<?php variable_del('memcache_wildcard_flushes'); ?>Fixed the issue.
#4
I'm glad the workaround works.
Could you let me know which version you upgraded from? 1.8 or something else?
There are only two ways to fix this in the code base:
1. Use a different variable name that doesn't conflict, leave the old one stale. I'd prefer to avoid this if we can.
2. Add an update to memcache_admin (and or a hunk in the new memcache.install) that does the variable_del() (possibly checking for the bad array structure).
The second only works for people running memcache_admin or who install the new memcache module, out of interest it'd be great if people who run into this could indicate whether they're running either - just to see whether that's worth adding or not.
#5
I had memcache_admin running, but I dont run it all the time. I just do it for checking stats, but after i get the info i want I'll disable it again. I was upgrading from 1.8. Most cases actually worked fine. It was only on my own account it starting throwing php errors.
#6
Coming from #1158444: Invalid argument supplied for foreach() in memcache_wildcards() which was marked as duplicate. I upgraded from 6.x-1.8 to 6.x-1.9 on two sites yesterday, and since got those severity=error messages on every page request:
Warning: Invalid argument supplied for foreach() in memcache_wildcards() (line 330 of /var/www/redhead-art/sites/all/modules/memcache/memcache.inc).On both sites, I deleted the 'memcache_wildcard_flushes' variable in mysql like suggested in #1:
mysql> DELETE FROM variable WHERE name = 'memcache_wildcard_flushes';Query OK, 1 row affected (0.00 sec)
In both cases, this had no effect in regard to the error.
How do I do that? I tried to create a node with PHP as input filter and this snippet:
<pre><?php
print_r($wildcard_flushes);
?>
</pre>
This returns empty (doesn't print an array); with
var_export()instead ofprint_r()it returns:NULL.Update: Additionally I ran
drush cc all, which finally seems to have eliminated the error.To see what of this would reproducable, I updated 'memcache' module on a third site; after replacing the module's files and before running update.php, the errors started to appear; the array snippet mentioned above returned
NULL; after running update.php, the snippet still returnedNULL. After saving the modules page the error was still there; the same after runningdrush cc all. With a delay of abount 120 seconds and an additional 'Flush all caches' from 'admin_menu' the error seems to be gone on the third site as well.On a fourth site, I updated the module and just cleared the caches, and waited a couple of minutes; the error did not go away. So at least on the sites I checked, it seems to be necessary to delete the variable in mysql and to clear the caches.
#7
subscribe, same error on
one of our 4 sitesall sites we upgraded to 1.9 Today.<?phpvariable_del('memcache_wildcard_flushes');
?>
with a clear cache fixed the issue for us.
The array looks like this
Array
(
[cache_page] => Array
(
[0] => 1287785099
)
[cache_menu] => Array
(
[11] => 1303860610
[18] => 1297971878
[17] => 1304103671
[20] => 1297789249
[ad] => Array
(
[11] => 1305575172
)
[li] => Array
(
[17] => 1305575172
)
)
[cache_content] => Array
(
[13] => 1301926188
[14] => 1302529533
)
[cache] => Array
(
[14] => 1304020960
[21] => 1303759395
[22] => 1304545337
[20] => 1303860610
[th] => Array
(
[14] => 1305575172
)
)
[cache_views_data] => Array
(
[4] => 1295290443
[6] => 1301351849
[11] => 1299175884
[20] => 1302823957
[12] => 1301698322
[14] => 1302111193
)
[cache_filter] => Array
(
[2] => 1297798134
)
)
And it's only getting thrown on cache_filter
which I have set to go to the database; this is set to default, not the database; next one down (cache_form) is set to the database.$table = cache_filter
$wildcard_key = 2
On a server that I fixed it on, the array is empty
#8
Here's a patch which ought to fix this without manual intervention (although I haven't tested it yet).
We need to workaround the fact that memcache can't run updates, and I don't want to add loads of special casing checking for variable structure based on old versions, so I've added a wrapper around variable_get() that versions the memcache variables.
This will leave some stale variables in the database on old sites, but we can add cleanup code to memcache module/memcache_admin to delete those at some point.
I'm hoping this will fix the issue long term should we want to change variable structure again.
If you are hitting this, please test the patch.
If you don't want to apply the patch or run dev, you can still just delete the variable and clear caches.
#9
Spoke to Jeremy and he prefers adding an install/update hook to memcache.module, that works for me too, so I'll add a patch for that tomorrow instead.
#10
Reviewing the code base to track down this bug, the memcache_wildcard_timestamps was added in 1.5, and removed in 1.7. We then added it back with a totally different purpose in 1.9. Thus, this bug affects anyone that has at some point used 1.5 or 1.6, and didn't follow the 1.7 release notes to manually delete the variable. Now that memcache includes a .install file, we should perform this type of cleanup there.
#11
Subscribe. (Same issue, no additional data to provide.)
#12
Subscribing :)
#13
I'm running Memcache v1.4.6 with PECL extension Memcache v2.2.6 in Drupal 6.22 on PHP Version 5.2.17 on Mac OS X 10.6.8.
I configured Memcache to open 10 instances in my startup and then in settings.php assigned a set of bins.
<?php$conf = array(
// The path to wherever memcache.inc is. The easiest is to simply point it
// to the copy in your module's directory.
'cache_inc' => './sites/all/modules/memcache/memcache.inc',
'memcache_key_prefix' => 'mysite',
'memcache_servers' => array(
'127.0.0.1:11211' => 'default',
'127.0.0.1:11212' => 'default',
'127.0.0.1:11213' => 'block',
'127.0.0.1:11214' => 'filter',
'127.0.0.1:11215' => 'form',
'127.0.0.1:11216' => 'menu',
'127.0.0.1:11217' => 'page',
'127.0.0.1:11218' => 'update',
'127.0.0.1:11219' => 'views',
),
'memcache_bins' => array(
'cache' => 'default',
'cache_block' => 'block',
'cache_filter' => 'filter',
'cache_form' => 'form',
'cache_menu' => 'menu',
'cache_page' => 'page',
'cache_update' => 'update',
'cache_views' => 'views',
),
);
?>
I changed those settings to delete a bin name and assignment and got the dreaded error :
warning: Invalid argument supplied for foreach() in /Users/me/Sites/mysite/sites/all/modules/memcache/dmemcache.inc on line 217.There are no statistics being reported for this bin.
Using PHP MyAdmin to delete variable 'memcache_wildcard_flushes' and a 'Clear Caches' from Performance in Drupal Admin cleaned things up and reformed my display at "http://mysite/admin/reports/memcache" to reflect the new settings.
Seems when the settings.php change, the admin module is unaware.
Hope this helps.
#14
@Cyberflyer: Just btw - if the handbook pages are correct, there is no need anymore to start multiple bins (except for better stats).
Have you tried the patch from #8? With which result?
#15
FYI:
I had the same problem, however, I was trying to run two separate drupal instances from the same virtual host. One worked great, however, one did not work at all... it rendered the aforementioned error. The difference between the two was in the settings file... something from the documentation I read wanted me to include this line, in the conf array, in the settings file:
'memcache_bins' => array('cache_page' => 'pages'),
The site that had this was broken, while the site that did not, worked like a champ. I removed the line from the conf array, and now both sites are sharing the memcached process just fine.
If I have overlooked something, please let me know.
Regards,
#16
Subscribe.
#17
I know this is only the symptom but can we at least kill the foreach error by maybe replacing isset with is_array?
#18
I think the warning is valuable. Since the data being returned in the variable_get is invalid, the function is not behaving the way it should be behaving. Without the warning, users would not know that their memcache_wildcard_flushes variable had the wrong/ineffective data and that the function is not working as intended.
I just went through all my sites after the memcache module 1.9 upgrade and issued the following command:
drush php-eval 'variable_del("memcache_wildcard_flushes");'; drush cc allProblem solved. I don't have the module enabled, so couldn't use anything in the install file.
Also, the solution proposed above with variable versioning makes me pull a sad face in that the drupal variable table already is too polluted with huge chunks of variables and really doesn't need any more cruft.
My suggestion to the memcache devs is to commit the update hook that deletes the variable to the install file, and to add something to the top of the README file for updaters from 1.6 or 1.5. More than that is overkill.
#19
I'm downgrading this since it only affects a particular subset of people upgrading, and there's a simple workaround. Agreed that the update hook would be useful.
#20
My hosting service, AN Hosting, has announced they are moving from PHP 5.2 to 5.3.10. I generated a 5.3.10 install of PHP on my dev machine that mirrors their configuration and am checking for any errors. One popped up and ironically Google sent me to this thread, where the above patch worked for me. This is a similar but, but different I think, however since I ended up here, I will post.
The error message is:
Warning: Invalid argument supplied for foreach() in /Users/larrylowe/Sites/fca-prod/sites/all/modules/memcache/dmemcache.inc on line 235
I get a Kumo Debug field at the top of the page and then the page renders normally.
The error message Drupal puts up in the content field reads:
There are no statistics being reported for this bin.
I deleted the line in settings above and saved settings.php and cleared the server caches and the error persists.
Answering my own question department.
I noticed that the error only persists on tabs in the admin page where there is no data cached for Memcache to report. That is the source error condition.
I removed the line in settings php for 'filters' and the problem went away.
Perhaps the wisest course is to just have one big memcache memory block and not the little bins I was using.
'127.0.0.1:11214' => 'filter',
Hosting server does not offer MemCache in shared hosting so it is not a production issue for me.
#21
Changing the title back as this is not a PHP 5.3.10 issue as I had thought.
PHP Version 5.3.10
Drupal 6.25
Apache 2.2.22
Mac OS X 10.6.8
Memcache 6.x-1.10
Memcache Admin 6.x-1.10