On my system, this script:

<?php

$n = $argv[1];

$backtrack_limit = ini_get('pcre.backtrack_limit');
$recursion_limit = ini_get('pcre.recursion_limit');

echo "Backtrack Limit: {$backtrack_limit}\n";
echo "Recursion Limit: {$recursion_limit}\n";

$pattern = '/^(.)*$/';
$subject = str_repeat('a', $n);

var_dump(preg_match($pattern, $subject));

...reports the default values (1,000,000 and 100,000 respectively) and matches when run with values 0-2729, and fails (returns false) with values 2730+.

Adjusting either limit to 1000 has no effect on when it fails, so this is probably some internal "maximum number of captures" which is unaffected by configuration.

If I change the regexp to /^.*x$/, it begins failing at the backtrack limit. It can still match above this limit if the subject actually matches.

I'm not having much luck tricking PCRE into crashing locally.

Since I can't really figure out how to make this stuff segfault or what reasonable ranges for these values are, I'm tentatively going to lower these values to 10000 in production (based on sage advice from Rasmus in https://bugs.php.net/bug.php?id=36463) and see what that breaks.

I'd ideally like to issue setup guidance about this, too, but I'd like a better understanding of it so I don't just have to write something like "u should probably set this to magic value X or spooky ghosts will attack ur computer".

We can detect this by testing the preg_match() return value for false. Our consistency on doing this isn't great.

I've deployed these configuration changes to production and they appear to have resolved the issue.