Posted 3 years ago #
When I started Wp super cache for a few hours, I get lots of error message in apache log which shows:
PHP Fatal error: Call to a member function get() on a non-object in D:\\web\\mwobetawp\\wp-includes\\cache.php on line 93
If I disable Wp super cache or in the first a few hours after it starts, this error never occurs.
Anyone can help me on this? Thanks.
Posted 3 years ago #
I don't think this is related to the wp-super-cache plugin. It doesn't use the object cache at all.
Posted 3 years ago #
Same problem here...I got a blank screen with the same error in the logs. The plugin has otherwise been working perfectly.
Renaming advanced-cache.php in the wp-content folder me get back in then I logged back in to admin, went to the plugin page (where it errored about the advanced-cache.php not being there), renamed the file back and then it was right again...
Cheers,
Chris.
Posted 3 years ago #
We have also started to get this exact error in the log since enabling the plugin. I haven't been able to trigger it myself. I'll see if I can get a backtrace to see what it happening.
Posted 3 years ago #
Ok, that wasn't altogether easy.
Backtrace is:
wp_cache_ob_callback, current_time, get_option, wp_cache_get
The problem here is that it is executed before the $wpdb object is set up.
Meaning it has to be from the early include of advanced-cache.php.
Not knowing the cache code a wild guess might be it somehow gets called early through the cron code?
Posted 3 years ago #
I think I know where it's happening.
current_time() is called in the callback. That's called during PHP's shutdown process. Unfortunately the shutdown process sometimes/at random kills off the objects used in the process before the script is actually finished working.
It's a PHP bug, and I read it was described as a chicken and egg problem.
I have a feeling this wasn't the case in earlier versions of PHP4, and only started to become a problem with PHP5 and later PHP4.
It's the same reason that gzip headers were sometimes not recorded in the meta files and I had to add a hack in wp-cache-phase1.php to add them back in. I literally watched my debug log as the headers were added to the meta object, and then somehow disappeared by the time the plugin was due to write them out. Very weird.
Posted 3 years ago #
Huh, weird.. :)
The server does use php 5 (5.2.4).
I'll replace current_time() with a plain gmdate() and see if I'll get new errors from something else.
Posted 3 years ago #
Any solutions to this yet? I got the same error after upgrading to the newest version of super cache yesterday. I have a heavy traffic site so i am eager to fix it.
Posted 3 years ago #
Ok, I can report that just changing current_time() to gmdate solves (or hides anyway) the problem for me. Before I got an error every hour or so. Now 24 hours without trouble.
So the rest of the objects seems to survive long enough.
It is an inelegant hack and doesn't solve whatever the root of the problem is.
What I did was changing current_time() in wp-cache-phase2.php : wp_cache_ob_callback() to gmdate('Y-m-d H:i:s').
If you care that the time is printed correctly in the html comment it should be: gmdate('Y-m-d H:i:s', (time() + (<your gmt offset> * 3600)))
Posted 3 years ago #
johanee - thanks for that. I'll make those changes, but I think the cache needs to use a different way of executing the callback. During shutdown is too late as it causes so many problems :(
Posted 3 years ago #
johanee - can you grab the development version from svn at http://svn.wp-plugins.org/wp-super-cache/trunk or the zip file development version on the download page. (Should update in the next 15 minutes)
I removed the PHP shutdown registration, instead calling it from the output buffer callback. Hopefully the output buffer gets processed early on in the shutdown!
Posted 3 years ago #
One of my sites had this bug (the other uses memcached and seems to be immune). The development version fixes this bug there so I'd like to hear if it works for anyone else too!
Posted 3 years ago #
Installed files from zipped development version, will report back tomorrow.
Posted 3 years ago #
Sorry, fails in same way:
wp_cache_ob_callback, wp_cache_get_ob, current_time, get_option, wp_load_alloptions, wp_cache_get
Posted 3 years ago #
I don't think this is a PHP issue.
/includes/cache.php (object-cache) registers a shutdown callback before supercache does. They get called in the order they are registered, so the object-cache dies before supercache.
It follows then that function calls from the supercache shutdown callback that access the object-cache (like current_time does via get_option) will fail.
Posted 3 years ago #
Murmatron 2 - that's interesting. It's strange that it only happens some of the time, but I'll see if I can move the ob_start() up higher in the process..
Posted 3 years ago #
Strange. wpdb and the cache destructors are called twice during shutdown.
[03-Feb-2009 09:32:45] 3906 wpdb shutdown!
[03-Feb-2009 09:32:45] 3906 cache shutdown!
[03-Feb-2009 09:32:45] 3906 wpsupercache shutdown!
[03-Feb-2009 09:32:45] 3906 cache shutdown!
[03-Feb-2009 09:32:45] 3906 wpdb shutdown!
Posted 3 years ago #
And when I added a destructor to the cachemeta class this is what happened. It's a wonder the meta file generation happens at all correctly any more. I need to figure out if I can change the order of shutdown somehow.
[03-Feb-2009 10:20:21] 3974 wpdb shutdown!
[03-Feb-2009 10:20:21] 3974 cache shutdown!
[03-Feb-2009 10:20:21] 3974 cachemeta shutdown!
[03-Feb-2009 10:20:21] 3974 wpsupercache shutdown!
[03-Feb-2009 10:20:21] 3974 cachemeta shutdown!
[03-Feb-2009 10:20:21] 3974 cache shutdown!
[03-Feb-2009 10:20:21] 3974 wpdb shutdown!
Posted 3 years ago #
From reading http://ie2.php.net/register-shutdown-function I think I see the above because the server is running PHP5.
Registered shutdown functions execute before deconstructors in an object. The first shutdowns before wpsupercache are those, the ones after are the deconstructors.
Yes. That's it. I commented out the register_shutdown_function() calls and here's what was logged:
[03-Feb-2009 10:29:58] 4165 wpsupercache shutdown!
[03-Feb-2009 10:29:58] 4165 cachemeta shutdown!
[03-Feb-2009 10:29:58] 4165 cache shutdown!
[03-Feb-2009 10:29:58] 4165 wpdb shutdown!
Which would work perfectly well.
Posted 3 years ago #
I think the first wpdb and cache shutdown is via the shutdown callback which fires in PHP4 and PHP5, and the second is the direct call to __destruct(). The second will only appear with PHP5.
I'm assuming that the references (e.g. global $wpdb) to them are invalid after the first event.
It's pretty confusing though.
Posted 3 years ago #
I've rearranged the code a bit. The ob callback is removed, and instead a shutdown function is registered in wp-cache-phase1.php right at the start of the process and long before wpdb and cache.php are loaded. It seems to work and objects are destroyed in the right order.
Grab wp-cache-phase* from svn or below:
Posted 3 years ago #
Thank you donncha! I was having a TON of php errors in my logs. After grabbing the files all is now good. :) I hope the author see's this thread and updates the plugin for everyone else.
Posted 2 years ago #
Um... mprindle, just FYI: donncha is the plugin author. :-)
Speaking of which: it looks like you've licked the issue for me, as well (PHP 5.2.6 here) and, FYI, in my case it was typically prompted by visitors coming in from a Google (or Google Images) image search. So far, after using your two suggested files, I'm not seeing those pesky error messages anymore of
PHP Fatal error: Call to a member function get() on a non-object in [path-to] cache.php on line 93, referer: http://www.google.com/
(also happened with other localized Google portals, also Google Images)
Posted 2 years ago #
I want to sue the guy responsible for Murphy's Law. Right after I posted that, bam: another of those weird errors. But, at least it's very sporadic which still is progress.
This topic has been closed to new replies.
