Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Thanks for your fast reply. This is the output from the DebugDiag Analysis Report after installing the symbols from the Debug Pack. Hope it helps.


In httpd.exe_201126_135319.dmp the assembly instruction at php_opcache!zend_jit_trace_exit_is_hot+68 in c:\PHP\ext\php_opcache.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000004 on thread 162

Faulting Thread

Entry point   libhttpd!ap_run_generate_log_id+3ab0 
Create time   26.11.2020 13:52:36 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.0 

php_opcache!zend_jit_trace_exit_is_hot+68 [C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\ext\opcache\jit\zend_jit_trace.c @ 6916 + 4]     
0000000`00000002     0000000`00000003     0000000`00000000     0000000`00000000   
C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\ext\opcache\jit\zend_jit_trace.c @ 6916 + 4 

php_opcache!zend_jit_trace_exit+d3e [C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\ext\opcache\jit\zend_jit_trace.c @ 7343 + 47]     
00001d1`00000003     00000a7`01ebd940     00001d1`2baec730     0001000`00c44b40   
C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\ext\opcache\jit\zend_jit_trace.c @ 7343 + 47 

0x00001000`0800062b     00000a7`01ebd940     00001d1`2baec730     0001000`00c44b40     0001000`00aa2520    
0x000001d1`00000003     00001d1`2baec730     0001000`00c44b40     0001000`00aa2520     00001d1`2cfc7540    
0x000000a7`01ebd940     0001000`00c44b40     0001000`00aa2520     00001d1`2cfc7540     0000000`00000308    
0x000001d1`2baec730     0001000`00aa2520     00001d1`2cfc7540     0000000`00000308     0007ffe`40701b31    
0x00001000`00c44b40     00001d1`2cfc7540     0000000`00000308     0007ffe`40701b31     00001d1`2d00b048    
0x00001000`00aa2520     0000000`00000308     0007ffe`40701b31     00001d1`2d00b048     0000000`0000003d    
0x000001d1`2cfc7540     0007ffe`40701b31     00001d1`2d00b048     0000000`0000003d     00001d1`2ce79000    
0x00000308     00001d1`2d00b048     0000000`0000003d     00001d1`2ce79000     00001d1`2baec730    

php8ts!zend_string_tolower_ex+281 [C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\Zend\zend_operators.c @ 2670]     
0000000`00000000     0000000`00000000     0000000`00000000     0000000`00000000   
C:\php-snap-build\php80\vs16\x64\php-8.0.0-ts\Zend\zend_operators.c @ 2670

Assigning to dmitry in case he can guess at the cause here.

Unfortunately, the backtrace is not enough to guess the reason of the crash.
We need some way to reproduce the failure.

What could I do? I have a VisualStudio 2013 running on the machine, might this help? Any other parameters I could try in php.ini to make it work?

I tried to debug the process httpd by VS -> Debug -> Attach to Process. 

There are 2 httpd-processes, and I get for the first:

php_opcache.dll!zend_jit_trace_exit_is_hot(unsigned int trace_num, unsigned int exit_num) Line 6916	C
php_opcache.dll!zend_jit_trace_exit(unsigned int exit_num,  Line 7343	C
[External Code]	
php8ts.dll!00007ffaa0225d88()	Unknown

And for the second:

ntdll.dll!KiRaiseUserExceptionDispatcher()	Unknown
KernelBase.dll!00007ffacf202cb5()	Unknown
libapr-1.dll!00000000569d88bd()	Unknown
libapr-1.dll!00000000569d8752()	Unknown
mod_socache_shmcb.so!00007ffaa1f5169c()	Unknown
mod_ssl.so!00007ffaa1f25382()	Unknown
mod_ssl.so!00007ffaa1f15b57()	Unknown
libapr-1.dll!00000000569ce24e()	Unknown
httpd.exe!00007ff7ea281c6c()	Unknown
httpd.exe!00007ff7ea282fa4()	Unknown
[External Code]	

Thanks for looking into this!

Check what page causes the crash.
Try to reproduce the same crash, passing the script and CGI environment variables command line PHP (or PHP-CGI).
If the application doesn't use external resources (DB, etc) and doesn't contain sensitive data, you may just pack and send it to me (with instruction, how to reproduce the crash).

Otherwise, you need to track down to the problem yourself... You may catch the crash in debugger and check the PHP source position printing (char*)executor_globals.current_execute_data->func->op_array.function_name.val and executor_globals.current_execute_data->opline->lineno. Then try to isolate the function(s) involved into crash. This is not a simple task...

Also try to reproduce the same problem with opcache.jit=1205. If you see the same crash, try to isolate the problem with opcache.jit=1205 (it should be easier).

Thanks for your reply and all your hints! 

It all works with opcache.jit=1205 without problems.

Without opcache.jit=1205 (no setting for opcache.jit at all in the php.ini) this php-code crashes:

<?php
	print "Hello world\r\n";
	print $_SERVER["DOCUMENT_ROOT"]."\r\n";

	for ($i = 0; $i < 100; $i++)
	{	$b = file_exists($_SERVER["DOCUMENT_ROOT"]."/index.php");		
	}

	print "It worked";


When reducing the loop to run 50 times it works, but 100 times is too much and it crashes.

Hope this helps.

same situation,hope this bug can be solved quickly.

I wasn't able to reproduce the crash on test case from @martin.
Is it crashes on very first request (after web server start)?

I need a well reproducible test case to analyse and fix this.
Better, if it possible to reproduce the crash with CLI PHP (without Apache).
However, the problem may be especially related to Apache SAPI (ZTS or Windows ASLR).

I changed the code for testing a bit to make it independent from the webserver:
<?php
	print "Hello world\r\n";
	
	for ($i = 0; $i < 100; $i++)
	{	$b = file_exists("index.php");		
		print $i;
		var_dump($b);
	}

	print "It worked";

This code still crashes in Apache, but works fine with CLI.

I'm not sure what else I could do to make it reproducible for you, I already gave you the versions from Apache I'm using. What else could influence that it works for you and not for me and louisowen?