Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21984
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <43FC0CEB.7000408@fischer.name>
Date: Wed, 22 Feb 2006 08:04:11 +0100
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Ilia Alshanetsky <ilia@prohost.org>
CC: Nuno Lopes <nlopess@php.net>, PHPdev <internals@lists.php.net>, 
	rasmus@lerdorf.com
References: <005101c6373a$a6ef0170$0100a8c0@pc07653> <43FB9D99.5070302@prohost.org>
In-Reply-To: <43FB9D99.5070302@prohost.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] recover from a segfault
From: markus@fischer.name (Markus Fischer)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

[response is at the bottom]

Ilia Alshanetsky wrote:
> 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 ;-)
> 
>> 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.


Would this "reliable execution" also apply to creating the stack
overflow message and passing it the PHPs error handler?

I was just two days ago that we had, of course, an infinite recursion
bug in our software, but the application just segfaults. The hard part
was to find where it segfaults. If it would just give a tiny hint as to
where the problem might be, this would be so awesome (if, of course,
technical possible/feasable).

- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD/Azr1nS0RcInK9ARAk0KAJ4wnL2pRypacl0dqFjr2Bb5EN81KwCcDmKu
kiMDEVP6pB/jYov1DCB7JSU=
=zxbn
-----END PGP SIGNATURE-----