WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#3354 closed defect (bug) (fixed)

PHP 5.2 & Fatal error in cache.php

Reported by: pulponair Owned by: ryan
Milestone: 2.2 Priority: normal
Severity: normal Version: 2.1.3
Component: General Keywords:
Focuses: Cc:

Description

Since upgrading to php 5.2 i am constantly recieving the following error:

PHP Fatal error: Call to a member function get() on a non-object in /var/www/xyz/htdocs/wp-includes/cache.php on line 28.

This may be related to the object module changes applied in 5.2 since everthing worked fine using 5.1.6.
The error occurs when surfing wordpress without beeing logged in.

Attachments (2)

openid2.patch (790 bytes) - added by hvdkamer 8 years ago.
Fix to correct problem in cache.php
shutdown.diff (996 bytes) - added by ryan 8 years ago.

Download all attachments as: .zip

Change History (46)

comment:2 @pulponair8 years ago

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.

comment:3 @darkfate8 years ago

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.

comment:4 @darkfate8 years ago

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

comment:5 @darkfate8 years ago

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();
?>

comment:6 @darkfate8 years ago

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(); 
?>


comment:7 @markjaquith8 years ago

  • Keywords needs-patch added
  • Owner changed from anonymous to markjaquith
  • Status changed from new to assigned

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.

comment:8 @pzuidhoek8 years ago

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

comment:9 follow-up: @ryan8 years ago

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

comment:10 @markjaquith8 years ago

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?

comment:11 @ryan8 years ago

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

comment:12 in reply to: ↑ 9 @pzuidhoek8 years ago

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

comment:13 @shorty1148 years ago

Can we mark this as fixed then?

comment:14 @shorty1148 years ago

  • Milestone set to 2.0.6

comment:15 @Mike_Koepke8 years ago

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

comment:16 @markjaquith8 years ago

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

comment:17 @markjaquith8 years ago

  • Milestone changed from 2.0.6 to 2.0.7

comment:18 @Mike_Koepke8 years ago

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.

comment:19 @kelson8 years ago

This still happens in WordPress 2.0.6.

PHP 5.2.0 on Linux.

comment:20 @markjaquith8 years ago

  • Owner changed from markjaquith to ryan
  • Status changed from assigned to new

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

comment:21 follow-up: @ryan8 years ago

[4686] tries some of the destruct tricks.

comment:22 @markjaquith8 years ago

  • Milestone changed from 2.0.7 to 2.1

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

comment:23 follow-up: @foolswisdom8 years ago

  • Keywords needs-testing added; needs-patch removed

#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)

comment:24 in reply to: ↑ 23 @foolswisdom8 years ago

  • Keywords needs-testing removed

Replying to foolswisdom:

Oops, that comment was meant for ticket:3528

comment:25 @Denis-de-Bernardy8 years ago

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

comment:26 @Denis-de-Bernardy8 years ago

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

D.

comment:27 @markjaquith8 years ago

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?

comment:28 @Denis-de-Bernardy8 years ago

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

comment:29 @Denis-de-Bernardy8 years ago

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

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

comment:30 @ryan8 years ago

  • Milestone changed from 2.1 to 2.0.8

comment:31 @markjaquith8 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:32 @kelson8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.0.5 to 2.1.1

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?

comment:33 @rob1n8 years ago

  • Milestone changed from 2.0.8 to 2.1.2

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

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

comment:34 @ryan8 years ago

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

comment:35 @darkfate8 years ago

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.

comment:36 @foolswisdom8 years ago

  • Milestone changed from 2.1.3 to 2.2

comment:37 @rob1n8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:38 @hvdkamer8 years ago

  • Resolution fixed deleted
  • Severity changed from blocker to normal
  • Status changed from closed to reopened
  • Version changed from 2.1.1 to 2.1.3

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...

@hvdkamer8 years ago

Fix to correct problem in cache.php

comment:39 @ryan8 years ago

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

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

@ryan8 years ago

comment:40 @ryan8 years ago

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

comment:41 @ryan8 years ago

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

comment:42 @ryan8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:43 in reply to: ↑ 21 @hakre5 years ago

Replying to ryan:

[4686] tries some of the destruct tricks.

Maybe the trick here was that while using register_shutdown_function the object will never be destroyed because the callback still uses it (and therefore it will exist until the very end of the script).

Return true; on a __destruct() magic function does nothing as far as I know.

Note: See TracTickets for help on using tickets.