|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70110 preg_match problem
Submitted: 2015-07-22 09:04 UTC Modified: 2020-06-16 13:17 UTC
Avg. Score:4.7 ± 0.6
Reproduced:14 of 14 (100.0%)
Same Version:6 (42.9%)
Same OS:5 (35.7%)
From: bugzilla77 at gmail dot com Assigned: sjon (profile)
Status: Closed Package: PCRE related
PHP Version: 7.0.0beta1 OS: *
Private report: No CVE-ID:
 [2015-07-22 09:04 UTC] bugzilla77 at gmail dot com
Regresion (PHP 5.6.11 no bugy)

Test script:

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-22 12:05 UTC]
-Status: Open +Status: Verified -Package: *General Issues +Package: PCRE related -Operating System: windows 7 32bit +Operating System: *
 [2015-07-22 12:05 UTC]
That's related to the PCRE-JIT compilation which is available as
of PHP 7. When pcre.jit=0 it works as expected.
 [2015-07-22 14:03 UTC]
-Status: Verified +Status: Suspended -Assigned To: +Assigned To: cmb
 [2015-07-22 14:03 UTC]
Well, that appears to be a bug in libpcre. I've filed a respective
report[1], and suspend this ticket for now.

[1] <>
 [2015-07-23 10:16 UTC]
-Status: Suspended +Status: Analyzed
 [2015-07-23 10:16 UTC]
No, not a bug in libpcre. PHP has to cater to PCRE_ERROR_JIT_STACKLIMIT.
 [2015-08-13 11:26 UTC] me at kelunik dot com
There's an even easier case that fails:

    preg_match('~(a)*~', str_repeat('a', 5431), $match);
 [2015-08-25 23:56 UTC]
-Status: Analyzed +Status: Suspended
 [2015-08-25 23:56 UTC]
After some discussion on the internals list[1], the current stance
is to stick with this behavior for now, i.e. return FALSE if the
regex can't be executed due to JIT limitations, and make that info
available via preg_last_error(), see <>.

Further improvements have to be postponed until PHP 7.1 at least,
so I'm suspending the ticket for now.

[1] <>
 [2017-05-03 10:01 UTC] hristochonov at gmail dot com has commented on [2015-08-25 23:56 UTC]:
"Further improvements have to be postponed until PHP 7.1 at least,
so I'm suspending the ticket for now."

PHP 7.1.0 has been released on 01 Dec 2016. It will be great if it would be possible to bring the issue forward now. We are experiencing this bug pretty often and have to always manually turn off PCRE-JIT in code for known regular expressions going to crash.
 [2017-05-03 11:23 UTC]
-Status: Suspended +Status: Open -Assigned To: cmb +Assigned To:
 [2017-05-03 11:23 UTC]
Thanks for the reminder – I don't have time for this, though.
 [2017-05-03 11:31 UTC] mk at bio dot logis dot de
Just want to point out that Drupal's and Symfony's YAML parsing are affected by this bug as well:
 [2017-05-31 13:16 UTC] donatj at gmail dot com
As it stands, retuning false is a very bad behavior. We have thousands of regexes in hundreds of code bases that just worked but fail at random in PHP7. Having to now check every single one for JIT stack over flow every single time is a MAJOR hassle. I would have strongly preferred an exception or a warning that would at least automatically shown up in our logs, but right now our existing code bases fail silently which is the worst of all worlds.
 [2017-09-04 10:12 UTC]
This just hit us here:

And the regex we use is '/^\* (OK|PREAUTH)/i', and this just silently does not match where it should.

Please, give it a higher prio. A warning in the log is really needed for such cases.
 [2017-11-09 11:31 UTC] stanislav dot khromov at gmail dot com
Here is a pull request to bump the maximum stack size to 512K, as recommended by the PCRE docs.
 [2019-02-21 21:11 UTC]
-CVE-ID: +CVE-ID: 2018-20783
 [2019-02-21 21:12 UTC]
-CVE-ID: 2018-20783 +CVE-ID:
 [2020-06-16 13:17 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: sjon
 [2020-06-16 13:17 UTC]
fixed since 7.3
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Feb 27 04:01:32 2024 UTC