php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #79992 register_shutdown_function(): Invalid shutdown callback
Submitted: 2020-08-18 20:50 UTC Modified: 2020-08-20 11:29 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: ASchmidt at Anamera dot net Assigned: cmb (profile)
Status: Not a bug Package: opcache
PHP Version: 7.4.9 OS: Windows x64 IIS
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ASchmidt at Anamera dot net
New email:
PHP Version: OS:

 

 [2020-08-18 20:50 UTC] ASchmidt at Anamera dot net 
Description:
------------
register_shutdown_function for existing class method will result in warning 
"PHP Warning:  register_shutdown_function(): Invalid shutdown callback"

In two other scenarios, existing instance method is reported as non-existing:
"Error: Call to undefined method".

If I disable/bypass the two code sections that reference the existing methods, then the rest of WordPress will load - or if I disable OPCACHE (or if I disable error reporting).

Happens without any added third party PHP extensions, using a freshly installed WordPress 5.5 on IIS x64 (FastCGI). Does NOT occur with PHP 7.3.21.

Test script:
---------------
// SCENARIO 1:

	if ( ! is_object( $handler ) || ! is_callable( array( $handler, 'handle' ) ) ) {
		$handler = new WP_Fatal_Error_Handler();
	}

	register_shutdown_function( array( $handler, 'handle' ) );


// SCENARIO 2:

		if ( WP_DEBUG && WP_DEBUG_DISPLAY ) {
			$this->show_errors();
		}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-08-18 23:30 UTC] ASchmidt at Anamera dot net 
I have spent the afternoon attempting to narrow this down - I tested with 7.4.8 and even 7.4.6 - and the problem persists.

I then took WordPress out of the picture, and just used the single-script OpCache GUI (https://github.com/amnuts/opcache-gui/releases/). That script will load ONCE, display valid figures and after it ran once, FastCGI will fail on page refresh.

I have attempted adding a Cache_ID, using the CWD option, setting up a different IIS application pool just for that one test site. Nothing makes a difference. The ONLY two things that work are - switch that site to run through PHP 7.3.21, or disable opcache.  Only then will the OpCache GUI project and/or WordPress 5.5 run.

Right now the problem looks like a general/generic problem with OpCache under 7.4 on IIS FCGI, but I realize that this is not a likely scenario to not have long since been encountered.
 [2020-08-19 09:18 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-08-19 09:18 UTC] cmb@php.net 
I can not reproduce this with opcache-gui-2.5.4 (haven't tried
with Wordpress).  Could you please provide a minimal php.ini with
which you can reproduce the issue (i.e. start with an empty
php.ini, and just add the necessary settings).  Also, does the
OPcache error log provide any insights (opcache.error_log set, and
opcache.log_verbosity_level=4)?
 [2020-08-20 05:23 UTC] ASchmidt at Anamera dot net
-Status: Feedback +Status: Assigned
 [2020-08-20 05:23 UTC] ASchmidt at Anamera dot net 
As requested, I've set up a fresh PHP 7.4.9 instance, empty PHP.ini, and a fresh web site. 

Along the way I stumbled across more places where classes supposedly don't exist and after a day of banging my head against walls everywhere, was able to extract it down to one simple/mininal case -- with huge impact. 

It appears that any subclasses that are defined BEFORE the parent class could be referenced in code prior to the class definitions under 7.3.21 - but will NOW FAIL as non-existing in 7.4.9.

I don't know yet, if THIS is the root cause - but I'll report the following separately as a 7.4.9 problem. I'll keep testing... but this may not be an OpCache-specific problem:

<?php
declare(strict_types=1);

var_dump( class_exists( 'MySubclass1' ), class_exists( 'MySubclass2' ), class_exists( 'MyAbstract' )  );	// PHP 7.4.9 = FALSE, true, true (PHP 7.3.21 = TRUE, true, true)

class MySubclass1 extends MyAbstract{}
abstract class MyAbstract{}
class MySubclass2 extends MyAbstract{}

var_dump( class_exists( 'MySubclass1' ), class_exists( 'MySubclass2' ), class_exists( 'MyAbstract' )  );	// true, true, true
    
// Produced with empty php.ini !
 [2020-08-20 06:44 UTC] ASchmidt at Anamera dot net 
THIS seems to be OPCACHE clashing with UOPZ (the June 2020 release) - if BOTH are active under Win x64 IIS FastCGI, then out-of-the-box WordPress will fail after refreshing home page thrice.

extension=uopz
zend_extension=php_opcache.dll

If EITHER extension is removed, then all will function.
OR, if stepping back to PHP 7.3.21, then both extensions will happily co-exist.
 [2020-08-20 11:29 UTC] cmb@php.net
-Status: Assigned +Status: Not a bug
 [2020-08-20 11:29 UTC] cmb@php.net 
> THIS seems to be OPCACHE clashing with UOPZ (the June 2020
> release) […]

Thanks for tracking this down!  I can confirm the incompatibility,
but since it's an uopz issue, I'm closing this ticket in favor of
<https://github.com/krakjoe/uopz/issues/129>.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 03:01:29 2024 UTC