php.net |  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-07-21 12:19 UTC
From: rfcastro at porto dot ucp dot pt Assigned: cmb (profile)
Status: Closed Package: JIT
PHP Version: 8.0.2 OS: Windows Server 2012 R2
Private report: No CVE-ID: None
 [2021-02-09 17:14 UTC] rfcastro at porto dot ucp dot pt
Description:
------------
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.

My PHP.INI:
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=100M
opcache.jit=1255
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.max_wasted_percentage=5

Test script:
---------------
File1:
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' => 'http://tempuri.org/WebServiceSAPI/Service1/Execute','uri' => 'http://tempuri.org/WebServiceSAPI/Service1'));
$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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-02-09 20:25 UTC] cmb@php.net
-Status: Open +Status: Feedback -Package: Unknown/Other Function +Package: JIT -Assigned To: +Assigned To: cmb
 [2021-02-09 20:25 UTC] cmb@php.net
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] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2021-02-10 12:09 UTC] cmb@php.net
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
implementation.
 [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] cmb@php.net
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: 8.0.2.0, 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?
 [2021-06-05 18:48 UTC] simbiat at outlook dot com
Crashing like this can also happen, when there is a web server (Apache in my case) and CLI running (I have a scheduled job) at the same time. In my case CLI version of the process crashes periodically and WinDBG shows this when analyzing the dump: https://apaste.info/KEfY
Using a separate opcache ID does not seem to help with this either. But, since below is about opcache, perhaps this is also related to this bug: https://bugs.php.net/bug.php?id=80881 since it also complains about access violation.
 [2021-06-07 18:19 UTC] simbiat at outlook dot com
While investigating this error I've stumbled upon https://bugs.php.net/bug.php?id=79535 and tried different optimization levels suggested there - it did not matter, but disabling opcache for CLI did resolve the issue, meaning, that issue is somewhere in the opcache.
I am not using Xdebug (at least not yet), though, so can't check whether enabling it will affect the issue somehow.
 [2021-07-18 23:12 UTC] dktapps at pmmp dot io
I guess this is the same as #81206. There's a possible fix up at https://github.com/php/php-src/pull/7208.
 [2021-07-21 12:19 UTC] nikic@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2021-07-21 12:19 UTC] nikic@php.net
I believe this has recently been fixed by https://github.com/php/php-src/commit/ef77d3c89f3ca7750b78a7974ebb82d8b116506f (not yet released).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 02:01:29 2024 UTC