OK, I've made a patch for you:
http://mega.ist.utl.pt/~ncpl/php_pcre_match_limit.txt
adds: pcre.match_limit and pcre.match_limit_recursion.
BTW, I think we should print a warning when pcre_exec() fails. Currently we
just fail silently.
Nuno
----- Original Message -----
I was just thinking of adding a couple of INI settings that scripts can
use to set match and match recursion limits.
-Andrei
On Apr 7, 2006, at 9:36 AM, Nuno Lopes wrote:
andrei Thu Apr 6 22:37:42 2006 UTC
Modified files:
/php-src/ext/pcre TODO
Log:
That is not the bug you're looking for.
http://cvs.php.net/viewcvs.cgi/php-src/ext/pcre/TODO?
r1=1.4&r2=1.5&diff_format=u
Index: php-src/ext/pcre/TODO
diff -u php-src/ext/pcre/TODO:1.4 php-src/ext/pcre/TODO:1.5
--- php-src/ext/pcre/TODO:1.4 Thu Apr 6 22:02:02 2006
+++ php-src/ext/pcre/TODO Thu Apr 6 22:37:42 2006
@@ -1,7 +1,8 @@
- Allow NULL for $matches argument (helps when using preg_match only
for
match condition) - might not be possible
-- http://bugs.php.net/bug.php?id=36975
+- http://bugs.php.net/bug.php?id=36983
+ http://bugs.php.net/bug.php?id=33151
regarding the last bug, there are several ways to fix it.
the PCRE's match() function is recursive and it consumes more than 100
bytes per call and the current recursion limit is 10 Millions. That
leaves us with 1 GB of stack that can be consumed. The problem is that
PHP will segfault after reaching the per-process stack limit.
My Gentoo box has a limit of 8 MBs of stack per process. Solaris too.
FreeBSD increases that to 64 MBs.
So, we need to tune the MATCH_LIMIT and MATCH_LIMIT_RECURSION parameters
to more realistic limits. we can force a hard limit that is more
realistic with nowadays stack limits, add a configure option, estimate
the max recursion depth at runtime (this can be passed as a parameter to
the function), etc...
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
