php opcache problem (Class not found errors)

[voku]

Bug report

I see "Class not found errors" e.g. Class 'Arrayy\TypeCheck\TypeCheckInterface' not found after or while running PHPStan. In this case, I try to run PHP-CS-Fixer after PHPStan, and it seems that PHP generated broken opcache files, so that PHP-CS_Fixer could not run anymore.

• I see that problem after updating to 1.6.0 (with bleedingEdge).
• I really destroyed the LXC container and tried it again, nothing changed.
• After clearing the opcache (opcache.file_cache_only), the PHP code is running again.
• Maybe it's related to https://bugs.php.net/bug.php?id=81041 ?

---

Here is the content of an empty/broken? opcache file. (there should be more content in the file, or?)

cat /var/tmp/php7.4/opcache/377076abe2ab6ee0c4975c2061101f72/home/comain/vdmg/Framework/thirdparty/composer/voku/arrayy/src/TypeCheck/TypeCheckInterface.php.bin

TN�`/home/comain/vdmg/Framework/thirdparty/composer/voku/arrayy/src/TypeCheck/TypeCheckInterface.php

Link to the real file: https://github.com/voku/Arrayy/blob/master/src/TypeCheck/TypeCheckInterface.php

---

I only saw the problem because I used strace to analyze the problem, and I noticed that PHPStan tried to load the opcache file of the missing class. e.g.

openat(AT_FDCWD, "/home/comain/vdmg/Framework/thirdparty/composer/voku/arrayy/src/TypeCheck/TypeCheckInterface.php", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=563, ...}) = 0
openat(AT_FDCWD, "/var/tmp/php7.4/opcache/377076abe2ab6ee0c4975c2061101f72/home/comain/vdmg/Framework/thirdparty/composer/voku/arrayy/src/TypeCheck/TypeCheckInterface.php.bin", O_RDONLY) = 5
flock(5, LOCK_SH)                       = 0
read(5, "OPCACHE\000377076abe2ab6ee0c4975c20"..., 80) = 80
read(5, "\300\1\0\0\0\0\0\0\2\0\0\0\0\0@\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 752) = 752
flock(5, LOCK_UN)                       = 0
close(5)

But it seems random what opcache files are broken after a PHPStan analyse run. :-/ Any idea what I could do to debug that?

---

System-Info

cat /etc/issue
Ubuntu 18.04.6 LTS

php -v
PHP 7.4.29 (cli) (built: Apr 21 2022 10:16:17) ( NTS )

cat /etc/php/7.4/cli/conf.d/50-opcache.ini

[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1

; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli=1

; The OPcache shared memory storage size.
opcache.memory_consumption=1024

; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=64

; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
opcache.max_accelerated_files=100000

; The maximum percentage of "wasted" memory until a restart is scheduled.
;opcache.max_wasted_percentage=5

; When this directive is enabled, the OPcache appends the current working
; directory to the script key, thus eliminating possible collisions between
; files with the same name (basename). Disabling the directive improves
; performance, but may break existing applications.
opcache.use_cwd=1

; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
opcache.validate_timestamps=1

; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=0 ; For php-cli always validate php files

; File based OPCache (persistent opcode cache)
opcache.file_cache=/var/tmp/php7.4/opcache
opcache.file_cache_only=1 ; For php-cli use file-cache only
opcache.file_cache_consistency_checks=1

Did PHPStan help you today? Did it make you happy in any way?

I like to prevent bugs before they hit production, and PHPStan do a wonderful work on that front. :)

[mergeable]

This bug report is missing a link to reproduction at phpstan.org/try.

It will most likely be closed after manual review.

[ondrejmirtes]

PHP generated broken opcache files

I’m not surprised by that, it’s caused by AutoloadSourceLocator, but at least the PHPStan analysis itself should be fine and not affected by this.

[ondrejmirtes]

This should leave the cache uncorrupted after PHPStan run: phpstan/phpstan-src@fc251b4

Please test it as phpstan/phpstan 1.6.x-dev once this is finished: https://github.com/phpstan/phpstan-src/actions/runs/2243593935 Thanks.

[ondrejmirtes]

As for the actual PHPStan analysis being affected, it'f be nice if you could replicate that in a repository:

• Running With PHPStan 1.6.x
• With bleedingEdge enabled
• PHPStan analysis does not work with OPCache enabled

Thanks.

[voku]

I’m not surprised by that, it’s caused by AutoloadSourceLocator, but at least the PHPStan analysis itself should be fine and not affected by this.

It depends, I see the same problem in PHPStan, if I cancel the execution and start the PHPStan process again, I see similar errors in PHPStan itself. But yes, otherwise PHPStan is running fine and "only" the next PHP calls are failing.

This should leave the cache uncorrupted after PHPStan run: phpstan/phpstan-src@fc251b4

opcache_reset (https://www.php.net/manual/en/function.opcache-reset.php): "This function only resets in-memory cache, not the file cache." ... so it maybe helps for in memory opcache issues, but in the CLI it makes more sense to use opcache.file_cache_only because we only have single processes.

As for the actual PHPStan analysis being affected, it'f be nice if you could replicate that in a repository:

I already tried that but if I start the same LXC container e.g. on my local Ubuntu, I do not see the problem. :-/ I can manually remove the opcache rm -rf /var/tmp/php7.4/opcache/*, that should work. I will try it today.

PS: thanks for the prompt answer :)

[ondrejmirtes]

Alright, reverted that opcache_reset commit.

My thinking is that your issues must be caused by one of the following:

• Referencing constants from the classes that are reported as not found (their opcache is corrupted)
• PHP 8.0 Attributes
• PHP 8.1 enums
• Using "new in initializers" - another PHP 8.1 feature

Can you confirm/deny that?

[staabm]

Maybe its related to a open php-bug, which can lead to autoloading issues, when files error and opcache is used.

See php/php-src#8063

[ondrejmirtes]

Not really, the problem is described and attempted to solve here (but it's not really possible, no one figured out how yet): phpstan/phpstan-src#801

[voku]

Manually remove the opcache rm -rf /var/tmp/php7.4/opcache/*; rm -rf /var/tmp/php8.0/opcache/*; is working as workaround for me. 👍

[staabm]

So couldn't phpstan itself delete the opcache files?

[ondrejmirtes]

I might have figured it out!

• phpstan/phpstan-src@ae53760
• phpstan/phpstan-src@28eaba2

Can you please try 1.6.x-dev once it builds? Thanks!

[ondrejmirtes]

Please test PHPStan 1.6.4 :)

[voku]

I tested PHPStan 1.6.4, and I still see the same problem. I will manually remove the opcache for now because then it's working.

[ondrejmirtes]

Would be nice if you could reproduce the problem.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.