PCRE pattern cache crashes process in wrapper stream_close called after shutdown

[nicolaslegland]

Description

The following code:

<?php

\preg_replace('/pattern/', 'replace', 'subject');

class wrapper
{
	public function stream_open($path, $mode, $options, &$opened_path)
	{
		echo __METHOD__.PHP_EOL;
		return true;
	}

	public function stream_close()
	{
		echo __METHOD__.PHP_EOL;
		\preg_replace('/pattern/', 'replace', 'subject');
	}

	public $context;
}

echo \php_sapi_name().PHP_EOL;

\stream_wrapper_register('wrapper', 'wrapper');
$handle = \fopen('wrapper://', 'rb');

Resulted in this output (PHP 8.3.9, 8.3.0, 8.2.0, 7.4.0):

cli
wrapper::stream_open

ERRORLEVEL -1073741819 (0xC0000005) Access violation

Resulted in this output (PHP 8.1.0, 8.0.0):

cli
wrapper::stream_open

ERRORLEVEL -1073740791 (0xC0000409) Stack buffer overrun

But I expected this output instead:

cli
wrapper::stream_open
wrapper::stream_close

ERRORLEVEL 0

PHP Version

PHP 8.3.9, 8.3.0, 8.2.0, 8.1.0, 8.0.0, 7.4.0

Operating System

Windows 11 Pro, Build 22621.ni_release.220506-1250

[nicolaslegland]

Commenting out line 3 proceeds with the expected output, likely by not warming the global per-thread cache of compiled regular expressions with this specific pattern.

Replacing line 3 with the following line proceeds to the expected output, likely by initializing the cache yet not providing a subsequent hit when stream_close is called at shutdown:

\preg_replace('/another pattern/', 'replace', 'subject');

Replacing line 3 with the following block results in the unexpected output again, likely by exhausting the 4096 entries of the cache:

for ($index = 0; $index < 4096; ++$index)
{
	\preg_replace('/pattern '.$index.'/', 'replace', 'subject');
}

Using a loop count of 8192, 12288 or 16384 produce the unexpected output too.

Using a loop count of 4095, 4097, 8191, 8193, 12287, 12289, 16383 and 16385 produce the expected output.

[nielsdos]

Thanks for the report.
This could be fixed by moving away from the per request cache for CLI and unify it with the other type of cache.
This is a similar issue to another one we have with the cache that could be fixed in the same way.