|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80726 With any PHP 8 version I get crash running more than one CLI
Submitted: 2021-02-09 17:14 UTC Modified: 2021-02-15 08:54 UTC
From: rfcastro at porto dot ucp dot pt Assigned:
Status: Open Package: JIT
PHP Version: 8.0.2 OS: Windows Server 2012 R2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: rfcastro at porto dot ucp dot pt
New email:
PHP Version: OS:


 [2021-02-09 17:14 UTC] rfcastro at porto dot ucp dot pt
The error has occurred on these versions: 8.00, 8.01 and 8.02

I open two command line prompts (two windows) in both I run two php codes and I get a php_opcache.dll error in the Event log. Sometimes an unknown and sometimes PHP8.dll but most of the time it's php_opcache.dll

One php file only has a Hello World cicle, and the other php file opens has soap connection with a foreach. When I remove the foreach (foreach ($ise_sapiOutput->resultado as $aluno)), it works, if I put it in again PHP crashes.

If I run without JIT, it works. If I run two simple hello word files, also works.


Test script:
do {
 echo 'Hello World';
 sleep (5);
} while (1);

File 2, soap connection:
$ise_aParameters = array(
'Funcao'		=> 'GetAlunos',
'NivelComp'		=> 5,
'Certificado'	=> 1,
'FormatoOutput'	=> 2,
'PEntrada'		=> 'TpUtil=0; CdUtil=1; PwdUtil=sistema; AnoLectivo='.$isa_iAnoLectivo.$ida_sSAPICdAluno2,
'PSaida'		=> 'Estado DESC;NAluno;NomeCompleto;Email;CdCurso;DgCurso;CdFaculd;EmailInstitucional'

$ise_xmlString 	= false;
$ise_xmlString 	= $isc_sSoapClient->__soapCall('Execute', array($ise_aParameters), array('soapaction' => '','uri' => ''));
$ise_xmlString	= $ise_xmlString->ExecuteResult;
$ise_sapiOutput = new SimpleXMLElement($ise_xmlString);

if ($ise_sapiOutput->resultado->EstRes=='0') {
 foreach ($ise_sapiOutput->resultado as $aluno) {
  //the error ocorres here with the foreach cicle, if I remove it, no error		

Expected result:
A PHP crash, usually php_opcache.dll

Actual result:
both scrips should run without errors. If I turn off JIT, it works.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-02-09 20:25 UTC]
-Status: Open +Status: Feedback -Package: Unknown/Other Function +Package: JIT -Assigned To: +Assigned To: cmb
 [2021-02-09 20:25 UTC]
Would it work if you used two different opcache.cache_id, e.g.

    php -dopcache.cache_id=1 file1.php
    php -dopcache.cache_id=2 file2.php
 [2021-02-10 10:26 UTC] rfcastro at porto dot ucp dot pt
-Status: Feedback +Status: Assigned
 [2021-02-10 10:26 UTC] rfcastro at porto dot ucp dot pt
Yes, using the two different caches works.

But is this possible automatically?
 [2021-02-10 12:09 UTC]
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2021-02-10 12:09 UTC]
On non Windows systems, OPcache instances are never shared between
unrelated PHP processes; only forked childs share the instance
with their parent.  Since there is FPM, this model works very
well.  On Windows, there is no FPM (and generally no fork(3)), so
all PHP processes using the same PHP version and SAPI share an
OPcache instance (until there is no more PHP process within that
group, in which case the OPcache instance is destroyed).  This is
required to have only a single OPcache instance for (F)CGI.  This
does not really make sense for typical CLI scripts, but there may
be cases where this is desired even for CLI.  Thus, the
opcache.cache_id INI option has been introduced, so that it's
possible to control the sharing of instances.

It might be sensible to automatically use separate OPcache
instances for CLI, if opcache.cache_id is not set, but that would
be a behavioral change.

I wonder, though, whether different OPcache instances are supposed
to be required in your case, or whether there is a bug in the JIT
 [2021-02-10 12:17 UTC] rfcastro at porto dot ucp dot pt
Right now I have it working placing the opcache.cache_id=2 on runtime on the main running script and the rest I have no opcache.cache_id, so I was guessing it would use 1 by default.

I see now in the PHP.ini there is an "opcache.cache_id=" commented. So should I place an opcache.cache_id=1 in the PHP.INI, or will it always used by default the opcache.cache_id=1 and since my main running code is on opcache.cache_id=2 it will work.
 [2021-02-10 13:34 UTC]
opcache.cache_id defaults to an empty string (the documentation is
wrong about the "1" default).  This default is different from any
other ID.

Note that ID is an arbitrary *string* (the documentation is
correct about that).
 [2021-02-10 13:38 UTC] rfcastro at porto dot ucp dot pt
So for Windows I should set in the PHP.INI opcache.cache_id=1 so any code will run always in opcache.cache_id=1

And manual if I have to run multi-codes at the same time, I should set each extra one with a opcache.cache_id=2 and opcache.cache_id=3, etc...

Is this correct?

And thank you for your time.
 [2021-02-15 08:54 UTC] rfcastro at porto dot ucp dot pt
The multi-run php cli seemed to go away like you said I still get once a week perhaps this error with JIT: msodbcsql17.dll . I did think perhaps it's when the code runs a bit faster, it's an synchronizer and when it doesn't find any changes, sometimes I get this error. I was thinking perhaps it's triggering the same problem the multi cache.

I have updated that DLL but it came back again. Perhaps some JIT buffer overflow? The code is working 24 hours none stop till I hit this error.

Event log:
Faulting application name: php.exe, version:, time stamp: 0x601adf99
Faulting module name: msodbcsql17.dll, version: 2017.177.1.1, time stamp: 0x6001e170
Exception code: 0xc0000005
Fault offset: 0x0000000000029a76
Faulting process id: 0xadc
Faulting application start time: 0x01d701c93dd362e3
Faulting application path: C:\Program Files\PHP\v8.0.2\php.exe
Faulting module path: C:\Windows\system32\msodbcsql17.dll

Do you want me to open a new bug or perhaps this has something to do with the opcache?
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Apr 13 09:01:24 2021 UTC