ID: 40846
Updated by: [EMAIL PROTECTED]
Reported By: crisp at xs4all dot nl
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
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..
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2007-03-17 20:16:03] crisp at xs4all dot nl
>Changing the limit doesn't mean removing the limit.
But if you change the default limits to match the defaults limits set
in PCRE internally you won't affect it's behavior compared to previous
versions of PHP where the internal settings in PCRE were not
overridden.
Either that or don't override PCRE's internal settings unless these
directives are explicitly set and enabled in php.ini (at the moment
these directives are commented in the php.ini samples).
------------------------------------------------------------------------
[2007-03-17 19:26:36] [EMAIL PROTECTED]
>that way there won't be a compatibility problem with previous
>versions of PHP as we have now.
Changing the limit doesn't mean removing the limit.
------------------------------------------------------------------------
[2007-03-17 19:19:57] crisp at xs4all dot nl
Description:
------------
The new pcre.backtrack_limit configuration directive is by default too
restrictive (100.000) which results in failure of many - often quite
simple - regular expressions.
I take it that this directive overrules the default setting for
MATCH_LIMIT in PCRE which will also imply that the naming of this
directive is wrong since MATCH_LIMIT is for every match() call in PCRE,
not only those for backtracking.
It would make more sense to change the default of both
pcre.backtrack_limit and pcre.recursion_limit to the ones that PCRE
itself also supplies (10.000.000 for both) - that way there won't be a
compatibility problem with previous versions of PHP as we have now.
Reproduce code:
---------------
$a = 'baab' . str_repeat('a', 100024);
$b = preg_replace('/b.*b/', '', $a);
Expected result:
----------------
I would expect $b to contain 100024 times 'a'
Actual result:
--------------
$b is a nullpointer, preg_last_error() reports '2' which is
PREG_BACKTRACK_LIMIT_ERROR
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=40846&edit=1
