PHP8.5: Opcache can crash in `do_implement_interface` when trait causes implicit `Stringable` interface addition
Personne n'a encore pris cette issue.
- Langage dominant
- C
- Étoiles
- 40.4k
- Forks
- 8.1k
- Merge moyen
- 2 j 13 h
- PR mergées (30 j)
- 96
Description
Description
Just expanding on the description a little, in the following conditions:
- PHP8.5 is used (8.4 at least is not affected)
opcache.enable&opcache.enable_cliare enabled (This may not requireenable_cliwith other SAPIs, but my issue was on the CLI / this is where I have narrowed down the issue)- A trait exists which has a
__toStringmethod - A class uses the above trait without declaring it implements
Stringable(the base class) - A sub-class in a different file extends the base class (regardless of if implements
Stringableor not)
With the above conditions, then if you have:
- A process that runs for at least the time for the second/third steps)
- A process runs that loads the base class into opcache's shared memory
- A process runs that loads the file the sub-class is in is ran
The process in step 3 will crash with an exit code of -1073741819 (0xC0000005 - STATUS_ACCESS_VIOLATION).
The above process will also cause the crash if the long running process loads the base class into opcache's shared memory - the important points are that when step 3 happens there is a process that was running when the base class was loaded - it isn't relevant if it is the process that did the loading or not.
Full code for replicating:
Main file
<?php
$mode = $argv[1] ?? "";
if($mode === "hold"){
\sleep(30);
echo "hold ok\n";
exit(0);
}
trait TestTrait{
public function __toString() : string{
return "testString";
}
}
class TestBaseClass{
use TestTrait;
}
switch($mode){
case "base":
echo "base ok\n";
exit(0);
case "sub":
require __DIR__ . "/subclass.php";
echo "sub ok\n";
exit(0);
}
subclass.php:
<?php
class TestSubclass extends TestBaseClass{}
Commands to run (terminal one):
php -n -d opcache.enable=1 -d opcache.enable_cli=1 test.php hold
Commands to run (terminal two):
php -n -d opcache.enable=1 -d opcache.enable_cli=1 test.php base
echo %errorlevel%
php -n -d opcache.enable=1 -d opcache.enable_cli=1 test.php sub
echo %errorlevel%
Resulted in this output (terminal one):
hold ok
Resulted in this output (terminal two):
base ok
0
-1073741819
But I expected this output instead (terminal one):
hold ok
But I expected this output instead (terminal two):
base ok
0
sub ok
0
PHP Version
PHP 8.4.6 (cli) (built: Apr 9 2025 09:45:15) (ZTS Visual C++ 2022 x64)
Copyright (c) The PHP Group
Zend Engine v4.4.6, Copyright (c) Zend Technologies
Operating System
Windows 11 x64
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par le fichier principal fourni et le reproducteur subclass.php, puis exécutez les deux séquences de commandes Windows CLI avec PHP 8.5 et Opcache activé. Vérifiez que le chargement de la classe de base suivi de celui de la sous-classe ne se termine plus par STATUS_ACCESS_VIOLATION et affiche à la place « sub ok » avec le code de sortie 0 ; l’issue ne désigne aucun fichier d’implémentation ni aucun test.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- php
- Domaine
- backend, performance
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Plutôt claire
- Accessibilité débutants
- 55/100