PHP 8.5.9 OPcache executes wrong internal functions (number_format → dechex, acos → hypot) under PHP-FPM

Description

Description

After upgrading to PHP 8.5.9, I am seeing apparent OPcache corruption under PHP-FPM where PHP executes a different internal function than the one present in the source code.

Examples from production:

Source code contains a call equivalent to:

number_format($latitude, 2)

but PHP throws:

ArgumentCountError: dechex() expects exactly 1 argument, 2 given

Stack trace:

#0 /home/.../src/Weather/templates/event-tracking.php(26): dechex('23.00000000', 2)
#1 /home/.../src/Weather/EventController.php(886): require_once(...)
#2 /home/.../public_html/weather/tropical-weather-events/2024-joyce.php(5): include(...)
#3 {main}

There is no dechex() call at this location in the source.

I have also received similar errors involving hypot(), where the source contains a different math function.

In addition to exceptions, some requests return mathematically incorrect numeric results without throwing an exception.

The problem occurs on both the production site and a test subdomain using the same application code.

OPcache/JIT testing

Initial configuration:

opcache.enable=1
opcache.validate_timestamps=1
opcache.revalidate_freq=15
opcache.jit=tracing
opcache.jit_buffer_size=128M

PHP:

PHP 8.5.9
ea-php85-php-8.5.9-2.3.1.cpanel
PHP-FPM / fpm-fcgi
Linux x86_64
cPanel EasyApache 4

JIT status showed tracing JIT enabled.

I first changed:

opcache.jit=disable

and restarted PHP-FPM.

The ArgumentCountError occurrences initially stopped, but incorrect numeric results later continued while OPcache remained enabled.

Redis/application caches were completely cleared and the incorrect numeric results remained.

Calling opcache_invalidate() on the affected PHP files immediately caused the same source code to begin producing correct results again.

Editing an affected source file and then restoring exactly the same PHP statement also caused the problem to temporarily disappear after OPcache recompiled the file.

Flushing OPcache caused behavior to change again. Some previously incorrect pages became correct, while wrong-function errors began occurring on other production requests.

Finally I set:

opcache.enable=0

and restarted PHP-FPM.

With OPcache completely disabled, both production and test have so far produced correct calculations and no wrong-function ArgumentCountErrors despite repeatedly loading the affected pages.

OPcache entry observed while problem was occurring

For one affected template:

Disk file:

mtime raw: 1786984725
size: 15902
md5: 3c9038dd4c9b0ba4e809cc60ddb1e45b

OPcache entry:

hits: 21
memory_consumption: 17104
last_used_timestamp: 1787045955
timestamp: 1786984725
revalidate: 1787045970

The OPcache timestamp exactly matched the filesystem mtime.

Version timing

Current PHP package:

Version: 8.5.9
Release: 2.3.1.cpanel
Install Date: Thu 13 Aug 2026 12:37:25 AM CDT

The issue was first noticed after this update when an affected template was edited and therefore recompiled by OPcache.

Expected result

PHP should execute:

number_format('23.00000000', 2)

Actual result

PHP sometimes executes an unrelated internal function using the same arguments:

dechex('23.00000000', 2)

resulting in:

ArgumentCountError: dechex() expects exactly 1 argument, 2 given

Disabling OPcache appears to eliminate the problem.

Additional information

APCu is not installed or enabled.

Cloudflare was ruled out for the incorrect page output:

cf-cache-status: DYNAMIC

Redis was completely flushed without resolving the incorrect numeric results.

Restarting PHP-FPM and/or invalidating specific OPcache entries changes the behavior.

The same application behaves correctly with OPcache disabled.

PHP Version

PHP 8.5.9 (cli) (built: Aug 12 2026 20:52:36) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.9, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.9, Copyright (c), by Zend Technologies

Operating System

AlmaLinux 8.10 x86_64

Bắt đầu bằng cách tái hiện hành vi gọi nhầm hàm trên PHP 8.5.9 với PHP-FPM và OPcache được bật, sau đó so sánh với trường hợp OPcache bị tắt và với việc vô hiệu hóa hoặc biên dịch lại có mục tiêu. Báo cáo không xác định tệp hay kiểm thử nào trong php-src; hoàn thành có nghĩa là xác định nguyên nhân trong OPcache và thêm một kiểm thử hồi quy để ngăn các lệnh gọi được phân giải thành những hàm nội bộ không liên quan.