Edit report at https://bugs.php.net/bug.php?id=79751&edit=1
ID: 79751
Comment by: personal at rysmax dot com
Reported by: buschmann at nidsa dot net
Summary: "VirtualProtect() failed" entries in apache
error.log
Status: Open
Type: Bug
Package: opcache
Operating System: Windows Server 2019 64bit
PHP Version: 8.0.0alpha1
Block user comment: N
Private report: N
New Comment:
I was investigating the same case.
I tested CMS EFFCORE on the Windows platform (Windows 10 2021 LTSC x64).
After installing Apache House (httpd-2.4.57-win64-VS17.zip) and PHP (php-8.2.11-vs16-x64.zip), I
began to include the missing modules to install the system.
I enabled all the required modules and the system installed without problems.
I ran all the tests and they ran successfully.
Then I decided to speed up the system and enabled OPCache + JIT.
After enabling OPCache + JIT I started getting a "white screen" and the message
"virtualprotect() failed 87 the parameter is incorrect".
After disabling OPCache + JIT or OPCache the problem went away.
I was wondering what this error was.
I created a small script and placed it in the "test.php" file.
It had the following contents:
$path = 'data.php';
$lines_num = 2000;
if (!file_exists($path)) {
file_put_contents($path, '<?php'."\n", FILE_APPEND);
for ($i = 0; $i < $lines_num; $i++)
file_put_contents($path, '$data['.$i.'] = \'value
'.$i."';\n", FILE_APPEND);
file_put_contents($path, 'print \'COUNT: \'.count($data);',
FILE_APPEND);
print 'FILE WAS CREATED. RELOAD THIS PAGE';
} else {
include_once($path);
print "\n".'FILE WAS INCLUDED';
}
Next, I ran âtest.phpâ from the browser and got a white screen if âlines_numâ
was greater than 2000 and a normal result if less than 2000.
This is an obvious overflow of some memory segment.
However, the log did not contain any information about the error.
From the console I ran this script with any number of "lines_num" and no problems arose.
php -d opcache.jit_debug=1 test.php
php -d opcache.jit_debug=1 data.php
I concluded that the problem is with the Apache + PHP combination as a module.
However, there were no problems under Linux/Unix.
Here is the complete list of links:
- win: Apache + PHP as a module - !!! JIT problem !!!
- win: IIS + PHP as FastCGI - OK
- win: PHP CLI - OK
- nix: Apache + PHP as a module - OK
- nix: NGINX + PHP as FastCGI - OK
- nix: PHP CLI - OK
I had to disable OPCache in "php.ini" via "opcache.enable=0" and the problem
went away.
In "php.ini" you can disable only JIT via "opcache.jit_buffer_size=0" but this
setting cannot be changed directly from PHP code.
Changing other "opcache.*" settings in "php.ini" did not lead to anything.
You can also disable OPCache + JIT programmatically with the following code:
if (DIRECTORY_SEPARATOR === '\\') {
ini_set('opcache.enable', false);
}
Thank you for your attention, I hope it helped.
Previous Comments:
------------------------------------------------------------------------
[2022-12-27 11:36:14] cmswares dot com at gmail dot com
Confirmed on PHP 8.2.0 / Windows 10 (Apache/2.4.48 (Win64) OpenSSL/1.1.1l PHP/8.2.0). Experienced
when using default opcache settings. phpinfo() shows opcache.jit_buffer_size = 0 by
default. A setting that isn't present by default in php.ini. When I change that to e.g. 16M
from the default 0, the errors in Apache's error.log no longer appear when restarting httpd.
For the record, the error is:
> VirtualProtect() failed [87] The parameter is incorrect
...and I would get some 450-500 of these entries in one long queue (with no timestamp or other
information aside the above line), following:
> [mpm_winnt:notice] [pid 8332:tid 588] AH00354: Child: Starting 500 worker threads.
My production server is running PHP 8.1.4 on Centos 7 and also has the default
opcache.jit_buffer_size = 0. However, there are no errors on httpd restart. (N.B.
I'd love to know if that should be changed or not. Per documentation, 0 disables JIT --
although I still see opcache.jit tracing.)
Then, I assume this is related to the fact that Apache/Windows uses mpm_winnt while
Linux defauls to mpm_prefork, and this issue is specific to mpm_winnt and the
instantiation of child workers.
------------------------------------------------------------------------
[2022-12-12 05:54:28] pavlusha23 at gmail dot com
I have this problem on PHP 8.1.12
In my case, the php_svm extension was to blame. After disabling it, the problem disappeared.
opcache.jit works fine after that, but if XDebug is enabled, then opcache.jit is turned off, as
described in the documentation.
P.S. Test with 8.1.12 TS x64 + Windows 10 Pro 22H2 + php_svm 0.2.3
------------------------------------------------------------------------
[2022-12-12 05:50:43] pavlusha23 at gmail dot com
In my case, the php_svm extension was to blame. After disabling it, the problem disappeared.
opcache.jit works fine after that, but if XDebug is enabled, then opcache.jit is turned off, as
described in the documentation.
------------------------------------------------------------------------
[2022-07-22 17:01:26] php at protopia dot co dot uk
I am also having this issue with "php 8.1.7 win64 vs16" on windows 10 with "apache
2.4.54 win64 vs16".
AFAIK these are both the latest versions.
Disabling JIT does prevent the issue, however this is a workaround not a fix as (presumably) JIT
should be working for this combination.
------------------------------------------------------------------------
[2022-02-10 20:55:48] schreck06 at aol dot com
$> php -v
PHP 8.1.2 (cli) (built: Jan 19 2022 10:18:23) (ZTS Visual C++ 2019 x64)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
with Zend OPcache v8.1.2, Copyright (c), by Zend Technologies
with Xdebug v3.1.3, Copyright (c) 2002-2022, by Derick Rethans
Windows Server 2022
Build 20348.473
---
When starting the webserver (Apache) the error log is being spammed with:
VirtualProtect() failed [...] Incorrect parameter
---
Solved the issue by adding a line to the php config:
>> php.ini
[opcache]
opcache.jit=off
---
auto_globals_jit=Off
...does result in a performance loss while disabling 'opcache.jit' doesn't noticably
------------------------------------------------------------------------
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=79751
--
Edit this bug report at https://bugs.php.net/bug.php?id=79751&edit=1