Edit report at https://bugs.php.net/bug.php?id=80726&edit=1
ID: 80726
Comment by: simbiat at outlook dot com
Reported by: rfcastro at porto dot ucp dot pt
Summary: With any PHP 8 version I get crash running more than
one CLI
Status: Open
Type: Bug
Package: JIT
Operating System: Windows Server 2012 R2
PHP Version: 8.0.2
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2021-02-15 08:54:07] 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-02-10 13:38:36] 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-10 13:34:55] 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 12:17:58] 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 12:09:19] 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80726
--
Edit this bug report at https://bugs.php.net/bug.php?id=80726&edit=1