Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <009001c6379b$a169ec90$0100a8c0@pc07653>
To: "Ilia Alshanetsky" <ilia@prohost.org>
Cc: "PHPdev" <internals@lists.php.net>
References: <005101c6373a$a6ef0170$0100a8c0@pc07653> <43FB9D99.5070302@prohost.org>
Date: Wed, 22 Feb 2006 10:34:58 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] recover from a segfault
From: nlopess@php.net ("Nuno Lopes")

> 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