You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when (?: (non-capturing group) is changes to (?> (atomic group), it increases stack usage causing JIT matching to fail with the following error:
JIT stack limit exhausted
This is problematic in deeply recursive regexes as it seems atomic group adds at least +1 stack depth per recursion.
I would expect this to be handled stackless.
Here is an example where we had to reduce atomic group usage to workaround this issue: mvorisek/PHP-CS-Fixer@fbce0f4
The text was updated successfully, but these errors were encountered:
Depends on the pattern. Assertions and atomic blocks needs to be reverted when they fail. E.g: (?>(a))b this adds a capturing bracket, which needs to be reverted if b fails to match. Marks, start of match, etc. needs to be reverted as well. So entering to an atomic block / atomic assertion may trigger many variable savings. I remember the engine optimizes some simple cases, but this has limitations.
Currently, when
(?:
(non-capturing group) is changes to(?>
(atomic group), it increases stack usage causing JIT matching to fail with the following error:This is problematic in deeply recursive regexes as it seems atomic group adds at least +1 stack depth per recursion.
I would expect this to be handled stackless.
Here is an example where we had to reduce atomic group usage to workaround this issue: mvorisek/PHP-CS-Fixer@fbce0f4
The text was updated successfully, but these errors were encountered: