Nuno Lopes wrote:
In the last days I've exchanged some e-mails with PCRE's author because
of one more bug that appeared in our database about segfaults in PCRE
(related to stack overflows).
PCRE can consume a lot of stack, because of backtracking (thus
segfaulting PHP). Yesterday I've discovered that when using the
setrlimit() function, most segfaults can be avoided
(http://mega.ist.utl.pt/~ncpl/php_pcre_stack_limits.txt) :)
This sounds like an interesting idea, I think we need to consider it doing
for PHP in general rather then jut when PCRE is being used. The only thing
is that rather then setting the stack to infinity, perhaps a small value
can be used ;-)
Using it in PCRE is expecialy important! The new PCRE release (6.6) include
a protection against stack recursion overflows, but the usual linux stack
runs out of space before the protection code is triggered :) (although this
doesn't apply on windows, I think).
My idea was to do some testing and set the stack size to a reasonable limit
that would allow the pcre's protection code to kick in before the segfault.
But to do this, we must upgrade PCRE (I already did it on my pc).
I've done a little program for fun to show myself how to catch the
SIGSEGV signals and print a nice message.
(http://mega.ist.utl.pt/~ncpl/break-stack.html)
So, catching the signal is easy. What about recovery? Doesn't anyone has
experience in this area? Can this be done? (and in most
SAPIs/architectures?)
After SEGV or any memory problem has happened the situation is undefined.
Another words you cannot reliably continue the operation of the program.
Which is why termination and dumping of core is the lesser of all evils in
this case.
After reading some stuff, I think that recovering is a bit undoable (I
previously though that messing with the stack pointer would be easy...).
But setting the handler to run on a separate stack seems to be a clean and
stable solution. Its all handled by the OS. And then we could produce a nice
error message and log it (if error_log is On).
I'll also try to produce a patch for this :)
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
