OPcache bypasses the user-defined error handler for deprecations

[dtdesign]

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

[TimWolla]

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.

[tomasjanicek]

I have same problem on php version 8.4.1

[kkmuffme]

Works correctly for me (Rocky Linux)

[jmglsn]

Bug is still present on PHP 8.4.3.

[dtdesign]

(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

[DylanGD]

The bug is still present on PHP 8.4.4

[kbalashov1]

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.

[umpirsky]

The bug is still present on PHP 8.4.5.

[aszenz]

I can confirm this issue is present on our symfony app

[lewischadwick]

Confirmed this still happens on PHP 8.4.6 too.