PHP 5.2 & Fatal error in cache.php

See http://bugs.php.net/bug.php?id=39381

Temporary fix :

wp-includes/cache.php Line 28:

    if (!is_object($wp_object_cache)) {
    $wp_object_cache = new WP_Object_Cache();
    }

wp-includes/cache.php Line 187:

    if (!is_object($wpdb)) {
    $wpdb = new wpdb(DB_USER, DB_PASSWORD, DB_NAME, DB_HOST);
    }

quick n dirty but working.

Yeah, damn deconstuct. They marked the bug as bogus (even though it technically isnt), so I don't think it's getting fixed in the PHP. You can sorta fix it by calling register_shutdown_function on destruct, but destruct is still messed up. Although it gets rid of the error.

That's weird, I can't do a double underline, that makes the text underlined. O well.

You can also call destruct as a function in a class: <?php class Destruct {

function Destruct() {

return $this->construct(); // forward php4 to construct

}

function construct() {

// register destruct method as shutdown function register_shutdown_function(array(&$this, "destruct"));

return true;

}

function destruct() {

// finish stuff return true;

}

}

$obj = new Destruct(); ?>

We need an editing function:

<?php 
class Destruct {

    function Destruct() {

        return $this->__construct(); // forward php4 to construct

    }

    function __construct() {

        // register destruct method as shutdown function
        register_shutdown_function(array(&$this, "__destruct"));

        return true;

    }

    function __destruct() {

        // finish stuff 
        return true;

    }

}

$obj = new Destruct(); 
?>

5.2 is stable and this bug doesn't seem to be getting any traction on the PHP bug tracker, so this needs a patch.

What milestone will contain this patch? I am curious because my website is severely hindered by this bug.

Can you try out the 2.0.6 beta and let us know if it helps?

http://wordpress.org/beta/wordpress-2.0.6-beta1.zip

I've had access to a PHP 5.2 system, and haven't been able to trigger this error. We're going to need more information about how it is triggered. The reporter said "constantly" and "when surfing wordpress without being logged in." Does that mean on every hit? On certain types of actions or page views? Sporadically without rhyme or reason?

I put php 5.2 on my system and I don't see any problems either.

Apache/2.0.55 (Ubuntu) mod_fastcgi/2.4.2 PHP/5.2.0-0.dotdeb.3 with Suhosin-Patch mod_ssl/2.0.55 OpenSSL/0.9.8b configured

Ryan,

I did not have enought time to try out the full beta, but I merged the changes in cache.php and wp-settings.php. It did the job.

Peter

Can we mark this as fixed then?

This item still isn't fixed. I tried RC2 on a Windows 5.2 server and still have issues chocking on the get function.

We'll consider this as one of the first things to tackle for 2.0.7, but we really need to get 2.0.6 out the door.

Also, is this an issue with Trunk? If so, it should probably be tackled for 2.1

I tried it this morning with PHP 5.2.1-RC2 on a Windows XP system with 2.0.5. The problem still exists. The only way to get it working is to apply the cache.php quick and dirty fixes above. I will try again with 2.0.6 when it is released.

This still happens in WordPress 2.0.6.

PHP 5.2.0 on Linux.

Ryan's the big PHP guru, so I'm handing this one off. This likely needs fixing for both 2.1 and 2.0.7

[4686] tries some of the destruct tricks.

2.0.7 is too soon for this... lets see how it goes for 2.1 and then consider for 2.0.8

#wordpress-dev (02:27:48 AM) io_error: Otherwise it fails on PHP < 4.3.5 and/or if cgi.rfc2616_headers is set (it's off by default)

Replying to foolswisdom:

Oops, that comment was meant for ticket:3528

The fix would be nice in WP 2.0.7. Many hosts have been upgrading php installations lately.

The bug also gets worse when a function anywhere uses an output buffer.

D.

I'm cautious with any fix that is described with the word "tricks" ;-)

We have a bunch of tickets slated for 2.0.8, so a fix of some sort will go in soon. We just want 2.0.7 to basically be "2.0.6.1"

Denis, can I take your comment to mean that you've tested this fix and verified that it solves the problem?

The suggested fix worked on my laptop, yes. But inserting this in function.php did so as well:

# fix php 5.2

if ( !function_exists('ob_end_flush_all') ) :
function ob_end_flush_all()
{
	while ( @ob_end_flush() );
}

register_shutdown_function('ob_end_flush_all');
endif;

I was only getting the bug when I was using output buffers. Forcing the output buffer to flush before the shutdown occurs (and thus before variables are destroyed) fixed this issue and many others I was getting.

Please be so kind to keep the conditional wrapper if you decide to use the above code. I'd hate to end up with function name collisions with my own scripts.

Denis

my php bug report doesn't seem to interest them...

http://bugs.php.net/bug.php?id=40104

(In [4841]) Fiddle with object destruction and shutdown. Curses upon php 5.2. fixes #3354

I still see this on WordPress 2.1.1 with PHP 5.2.1:

"PHP Fatal error: Call to a member function get() on a non-object in /path/to/wp-includes/cache.php on line 32"

And it still stops processing single-post pages before displaying the comments area.

Was this only fixed in the 2.0 series?

It appears the fix only went into the 2.0 branch, yes.

Ryan: Can we put this in 2.1 and 2.2 SVN?

It's already in both 2.1 and 2.2. [4686]

This may be a user specific issue. If the temp directory isn't setup correctly, you'll get errors caching files. Say you set the temp folder to C:\Temp. If there is no Temp folder, it totally goes beserk.

Well, then it's an user misconfiguration error. We've fixed it as much as we can. If the user has a misconfigured server, well, then that's their fault and mistake.

After installing the wpopenid plugin I got the following error:

[19-Apr-2007 15:50:15] PHP Fatal error:  Call to a member function get() on a non-object in /var/www/hetlab.tk/www/wp-includes/cache.php on line 32

I'm using WordPress 2.1.3 on PHP 5.2.0-8+etch1 from Debian and /tmp is correct. After applying the fix by pulponair in the second post of this thread, the error was gone and the wpopenid plugin worked. I will try to attach my diff...

Fix to correct problem in cache.php

hvdkamer, does Denis patch work for you? I think that is a better fix if so.

http://trac.wordpress.org/ticket/3354#comment:28

Patch makes sure output buffers started by plugins are shutdown before objects are destroyed.

(In [5462]) Flush all output buffers during shutdown to avoid PHP 5 bustage. see #3354

(In [5463]) Flush all output buffers during shutdown to avoid PHP 5 bustage. fixes #3354 for 2.2