ID: 40846
Comment by: brandon at invisionpower dot com
Reported By: crisp at xs4all dot nl
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2007-05-20 11:22:00] crisp at xs4all dot nl
PHP 5.2.0 includes an update of the PCRE library (version 6.7), so some
problems may not be totally due to the restrictive limits of the PCRE
settings in PHP but could be a bug/regression in PCRE itself.
PCRE has always been very poor in internal optimisation of expressions
that contain look-aheads or look-behinds, especially when they are
combined with some OR'ed subexpression. It's backtracking mechanism is
quite simplistic and doesn't rule out execution paths that are sure not
to result in a match - in fact, it doesn't have any sort of execution
planner.
------------------------------------------------------------------------
[2007-05-20 11:09:08] tigr at mail15 dot com
It is kinda strange: previous versions work pretty nice, swiftly
executing all patterns. And in some situations (as I mentioned before)
increasing recursion and backtrack limits just won't help. I suppose
it's wrong behaviour.
Also, note that examples are pretty short and simple. Increasing both
limits to 1 000 000 does not help - just why?
------------------------------------------------------------------------
[2007-05-20 10:49:37] [EMAIL PROTECTED]
we simply can't increase recursion limit or we risk segfaulting php.
increase the backtrack limit is also risky, but is much safer (although
regexes with much backtracking are usually not well written). I'll think
more about this..
------------------------------------------------------------------------
[2007-05-19 08:32:44] tigr at mail15 dot com
Sorry, little mistake: expected result not 'replaced replaced
replaced', but 'replaced replaced'.
------------------------------------------------------------------------
[2007-05-19 06:49:43] tigr at mail15 dot com
For me this new behaviour have broken my templates system. While some
of regexpes where simplified, others could not be done so. In some
situations increasing these numbers of little help. For instance(the
regexp was simplified greatly, in real-life application it is much more
complex):
<?php
echo preg_replace('/\$[a-z]+([a-z]*(?:\[[a-z]*\])?)*/i'
, 'replaced', '$abc $something[something]');
echo var_dump(preg_last_error());
?>
Expected result - 'replaced replaced replaced'. Actual result -
nothing, NULL returned, preg_last_error() shows that there is
PREG_BACKTRACK_LIMIT_ERROR error. Also increasing backtrack limit leads
to another error, PREG_RECURSION_LIMIT_ERROR. Increasing recursion limit
leads to php hanging up.
Changing first or second asterisk in pattern to plus sign immediately
fixes the problem, but I need it in this way. Also, do you think that
this is a correct behaviour? I thing there is a bug somewhere that way.
However, this works pretty well on php 4.x, 5.x and even at 5.2.1 (at
one of the hosts), but it does not work on my local php5.2.2 on
WinXPsp2.
------------------------------------------------------------------------
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
http://bugs.php.net/40846
--
Edit this bug report at http://bugs.php.net/?id=40846&edit=1
