OPcache bypasses the user-defined error handler for deprecations

@TimWolla

Description

The OPcache bypasses the user-defined error handler for deprecations for the first request with a cold cache. This happens regardless of opcache.record-warnings which only has an impact on all following requests. Enabling opcache.record-warnings will yield the expected behavior for every request after the first one which populated the cache.

This does not happen when OPcache is disabled, it will behave properly for every request.

test.php

<?php

set_error_handler(static fn (...$params) => var_dump($params));

require "./dependency.php";

implicitly_nullable_parameter(new stdClass());

dependency.php

<?php
function implicitly_nullable_parameter(stdClass $foo = null) {
    echo "Called\n";
}

This can be reproduced on a web server whenever opcache_reset() reset is invoked but for simplicity this was also verified to be triggered via CLI (thanks to @TimWolla for this suggestion):

$> php -dopcache.enable_cli=1 --repeat 2 test.php
Executing for the first time...
PHP Deprecated:  implicitly_nullable_parameter(): Implicitly marking parameter $foo as nullable is deprecated, the explicit nullable type must be used instead in /opt/homebrew/var/www/test/opcache-deprecations/dependency.php on line 2

Deprecated: implicitly_nullable_parameter(): Implicitly marking parameter $foo as nullable is deprecated, the explicit nullable type must be used instead in /opt/homebrew/var/www/test/opcache-deprecations/dependency.php on line 2
Called
Finished execution, repeating...
Called
$> php --version
PHP 8.4.2 (cli) (built: Dec 17 2024 15:31:31) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.2, Copyright (c), by Zend Technologies

(Note: There is a bonus bug hiding here, the deprecation message is printed twice. However, the first message starts with PHP Deprecated: (…) but the second message only reads Deprecated: (…).)

The script was also invoked manually via CLI without OPcache to verify that the behavior is identical to FPM:

$> php test.php
array(4) {
  [0]=>
  int(8192)
  [1]=>
  string(141) "implicitly_nullable_parameter(): Implicitly marking parameter $foo as nullable is deprecated, the explicit nullable type must be used instead"
*snip*

PHP Version

PHP 8.4.2

Operating System

macOS 15.1.1

OPcache explicitly clears the user error handler in:

php-src/ext/opcache/ZendAccelerator.c

Line 1806 in d8d1cb4

ZVAL_UNDEF(&EG(user_error_handler));

before compiling the file. This is done since the first version of the open source OPcache, so it's not clear to me, why it does this.

I have same problem on php version 8.4.1

Works correctly for me (Rocky Linux)

Bug is still present on PHP 8.4.3.

@TimWolla

(Note: There is a bonus bug hiding here, the deprecation message is printed twice. However, the first message starts with PHP Deprecated: (…) but the second message only reads Deprecated: (…).)

I stand corrected, this is caused by log_errors being enabled, thanks to @TimWolla for pointing this out:

$> php -dopcache.enable_cli=1 -dlog_errors=0 --repeat 2 test.php
Executing for the first time...

Deprecated: implicitly_nullable_parameter(): Implicitly marking parameter $foo as nullable is deprecated, the explicit nullable type must be used instead in /opt/homebrew/var/www/test/opcache-deprecations/dependency.php on line 2
Called
Finished execution, repeating...
Called

The bug is still present on PHP 8.4.4

Confirming seeing this issue, that specific deprecation ignoring our error handlers messes up our json outputs and blocks us from upgrading to 8.4. Fixing all deprecations isn't an option, as we can do so in our own code but not in the packages that we use.

The bug is still present on PHP 8.4.5.

I can confirm this issue is present on our symfony app

Confirmed this still happens on PHP 8.4.6 too.

opcache: Do not disable userland error handlers in `opcache_compile_f…

Is it still the same on PHP 8.4.7?

Is it still the same on PHP 8.4.7?

Yes it is for me.

bug #60779 Silence E_DEPRECATED and E_USER_DEPRECATED (nicolas-grekas)

Bug is still present in PHP 8.4.8

Fix error handling inconsistency with opcache

This has been fixed in version 8.5. Unfortunately this can not be fixed in earlier versions due to complexity and breaking changes.

A possible workaround for 8.4, when a user-defined error handler is in place, is to remove E_DEPRECATED from error_reporting: symfony/symfony@9a7f7a3. In effect, this will prevent displaying/logging E_DEPRECATED errors entirely (including during compilation), but will still call the user-defined error handlers (except during compilation): https://gist.github.com/arnaud-lb/47bc1e93f01e6740e2dbbc2e44b27f3d.

php84 needs nullable arguments to be explicitly nullable. You'd think…

Navigation Menu

Repository navigation

OPcache bypasses the user-defined error handler for deprecations #17422

Description

PHP Version

Operating System

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OPcache bypasses the user-defined error handler for deprecations #17422

Description

Description

PHP Version

Operating System

Activity

TimWolla commented on Jan 10, 2025

tomasjanicek commented on Jan 16, 2025

kkmuffme commented on Jan 17, 2025

jmglsn commented on Jan 20, 2025

dtdesign commented on Jan 29, 2025

DylanGD commented on Feb 25, 2025

kbalashov1 commented on Mar 13, 2025

umpirsky commented on Apr 9, 2025

aszenz commented on Apr 9, 2025

lewischadwick commented on Apr 16, 2025

vencakrecl commented on May 14, 2025

boewamwinter commented on May 21, 2025

Hanashi commented on Jun 24, 2025

arnaud-lb commented on Jul 27, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions