Edit report at https://bugs.php.net/bug.php?id=40846&edit=1
ID: 40846
Updated by: felipe@php.net
Reported by: crisp at xs4all dot nl
Summary: pcre.backtrack_limit too restrictive
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package: PCRE related
Operating System: *
PHP Version: 5.3
-Assigned To:
+Assigned To: felipe
Block user comment: N
Private report: N
New Comment:
This has been changed as of PHP 5.3.7 RC1.
"Increased the backtrack limit from 100000 to 1000000"
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2010-04-17 06:43:06] wclark at xoom dot org
Please just set the PHP limits to match the default PCRE limits. People asked for
that three years ago.. what's the holdup? I run into this problem quite regularly
when using UNGREEDY matches, which frankly makes no sense (why would UN-greedy
matches need more backtracking?) but I'll chalk that up to PCRE's poor
implementation. Regardless, if the PHP defaults were set higher I would never
encounter these issues in the first place.
------------------------------------------------------------------------
[2009-08-28 08:54:44] tom at r dot je
This is still an issue in 5.3.
The low limit causes scripts which hit it to fail without a warning, notice or error, creating hard
to track down bugs For example, something which works fine for one set of data stops working on
another set because the data is just longer.
This cannot be the expected behaviour, surely?
At minimum there needs to be a warning. Ideally though, the limit needs to be put to the pcre
defaults.
------------------------------------------------------------------------
[2007-12-10 14:18:11] daan at react dot nl
This issue is still a problem, plus this low setting is also the cause of segfaults.
(see http://bugs.php.net/bug.php?id=43031)
At the moment even this simple regexp segfaults 5.2.5:
preg_match('/(.)*/', str_repeat('x', 6000));
I hope that is not intended behavior, as is suggested in the reply in bug report 43031.
------------------------------------------------------------------------
[2007-08-16 19:00:13] drnick at physics dot byu dot edu
I just wanted to throw out that I completely agree with crisp. We recently updated PHP on our
webserver to 5.2.3 and had issues with our template system on input sizes of a certain size
(>100K).
The idea of allowing PHP to enforce limits on the PCRE library is fine, but having the default
action (when recursion_limit and backtrack_limit are commented-out) be PHP overriding PCRE's
internal limits is VERY problematic. Aside from being incredibly anti backwards-compatible, I
believe PHP should not make arbitrary assumptions such as these.
I believe PHP should be changed so that the default action is to make use of PCRE's internal
limits, and if people want to enforce their own, they can make that decision via the options.
Perhaps modify php.ini-recommended to explain the options and say why having external limits can be
good.
------------------------------------------------------------------------
[2007-08-16 15:58:08] brandon at invisionpower dot com
Installations of 5.2 are causing this issue for us with relatively simple regex. Users can submit
an arbitrary amount of data (I work on a bulletin board software) that is parsed out for bbcode
tags. Even simple expressions are causing problems.
$txt = preg_replace_callback( "#\[code\](.+?)\[/code\]#is", array( &$this,
'regex_code_tag' ), $txt );
var_dump( preg_last_error() );
The callback function is not being hit at all and the output is int(2) (backtrack limit hit).
Increasing backtrack limit to 1,000,000 "resolves" the issue, but with shared hosting
plans it's unrealistic to expect hosts to make php.ini changes to allow this.
I agree with crisp - the limit in PHP should bet set to the internal PCRE options, with the php.ini
settings allowing you to reduce them if you wish. PHP should not arbitrarily reduce them.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=40846
--
Edit this bug report at https://bugs.php.net/bug.php?id=40846&edit=1