php.net |  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
Votes:15
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:
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bugzilla77 at gmail dot com
New email:
PHP Version: OS:

 

 [2015-07-22 09:04 UTC] bugzilla77 at gmail dot com
Description:
------------
Regresion (PHP 5.6.11 no bugy)

Test script:
---------------
<?php
 var_dump(preg_match('/^(A{1,2}B)+$/',str_repeat('AB',8192)));
?>

Expected result:
----------------
int(1)

Actual result:
--------------
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-22 12:05 UTC] cmb@php.net
-Status: Open +Status: Verified -Package: *General Issues +Package: PCRE related -Operating System: windows 7 32bit +Operating System: *
 [2015-07-22 12:05 UTC] cmb@php.net
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] cmb@php.net
-Status: Verified +Status: Suspended -Assigned To: +Assigned To: cmb
 [2015-07-22 14:03 UTC] cmb@php.net
Well, that appears to be a bug in libpcre. I've filed a respective
report[1], and suspend this ticket for now.

[1] <https://bugs.exim.org/show_bug.cgi?id=1663>
 [2015-07-23 10:16 UTC] cmb@php.net
-Status: Suspended +Status: Analyzed
 [2015-07-23 10:16 UTC] cmb@php.net
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);

http://3v4l.org/CGSqa
 [2015-08-25 23:56 UTC] cmb@php.net
-Status: Analyzed +Status: Suspended
 [2015-08-25 23:56 UTC] cmb@php.net
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 <https://3v4l.org/IWGam>.

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

[1] <http://markmail.org/thread/6bcffpbcobyi3ln7>
 [2017-05-03 10:01 UTC] hristochonov at gmail dot com
cmb@php.net 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] cmb@php.net
-Status: Suspended +Status: Open -Assigned To: cmb +Assigned To:
 [2017-05-03 11:23 UTC] cmb@php.net
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:
https://www.drupal.org/node/2792877
 [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] alec@php.net
This just hit us here: https://github.com/roundcube/roundcubemail/issues/5932

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. 

https://github.com/php/php-src/pull/2910
 [2019-02-21 21:11 UTC] stas@php.net
-CVE-ID: +CVE-ID: 2018-20783
 [2019-02-21 21:12 UTC] stas@php.net
-CVE-ID: 2018-20783 +CVE-ID:
 [2020-06-16 13:17 UTC] sjon@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: sjon
 [2020-06-16 13:17 UTC] sjon@php.net
fixed since 7.3
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC