Hi,
PCRE can be highly recursive [1] and this can cause segmentation faults [2].
This is a known problem and the pcre ini settings avoids the segfaults, but
the execution of the expression will fail anyway.
PCRE has a NO_RECURSE flag which makes the match() internal function no
recursive and avoids this problem. The configure switch for this option is --
disable-stack-for-recursion. NO_RECURSE is documented in pcre_exec.c.
This can be easily enabled [3] for the bundled PCRE. It seems to be safe to
enable that. Actually the PCRE test suite pass with NO_RECURSE enabled, and
segfaults without. Can this be enabled ?
[1] http://manpages.courier-mta.org/htmlman3/pcrestack.3.html
[2] http://bugs.php.net/bug.php?id=45735
[3] http://arnaud.lb.s3.amazonaws.com/pcre_no_recurse.patch
Regards,
Arnaud
No!
Last time I benchmark it, it has about 100x slower, so I don't think so.. If
you need to match large amounts of data, just increase the stack size.
ulimit is your friend :)
Nuno
----- Original Message -----
From: "Arnaud Le Blanc" arnaud.lb@gmail.com
To: internals@lists.php.net
Sent: Thursday, August 07, 2008 1:24 PM
Subject: [PHP-DEV] PCRE and recursion: NO_RECURSE flag
Hi,
PCRE can be highly recursive [1] and this can cause segmentation faults
[2].
This is a known problem and the pcre ini settings avoids the segfaults,
but
the execution of the expression will fail anyway.PCRE has a NO_RECURSE flag which makes the match() internal function no
recursive and avoids this problem. The configure switch for this option
is --
disable-stack-for-recursion. NO_RECURSE is documented in pcre_exec.c.This can be easily enabled [3] for the bundled PCRE. It seems to be safe
to
enable that. Actually the PCRE test suite pass with NO_RECURSE enabled,
and
segfaults without. Can this be enabled ?[1] http://manpages.courier-mta.org/htmlman3/pcrestack.3.html
[2] http://bugs.php.net/bug.php?id=45735
[3] http://arnaud.lb.s3.amazonaws.com/pcre_no_recurse.patchRegards,
Arnaud
Sorry, I had not thought about that. I just checked with the example given in
the bug report and it's effectively slower (~25% on this expression).
On Thursday 07 August 2008 14:35:12 Nuno Lopes wrote:
No!
Last time I benchmark it, it has about 100x slower, so I don't think so..
If you need to match large amounts of data, just increase the stack size.
ulimit is your friend :)Nuno
----- Original Message -----
From: "Arnaud Le Blanc" arnaud.lb@gmail.com
To: internals@lists.php.net
Sent: Thursday, August 07, 2008 1:24 PM
Subject: [PHP-DEV] PCRE and recursion: NO_RECURSE flagHi,
PCRE can be highly recursive [1] and this can cause segmentation faults
[2].
This is a known problem and the pcre ini settings avoids the segfaults,
but
the execution of the expression will fail anyway.PCRE has a NO_RECURSE flag which makes the match() internal function no
recursive and avoids this problem. The configure switch for this option
is --
disable-stack-for-recursion. NO_RECURSE is documented in pcre_exec.c.This can be easily enabled [3] for the bundled PCRE. It seems to be safe
to
enable that. Actually the PCRE test suite pass with NO_RECURSE enabled,
and
segfaults without. Can this be enabled ?[1] http://manpages.courier-mta.org/htmlman3/pcrestack.3.html
[2] http://bugs.php.net/bug.php?id=45735
[3] http://arnaud.lb.s3.amazonaws.com/pcre_no_recurse.patchRegards,
Arnaud