Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51644 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33532 invoked from network); 9 Mar 2011 16:01:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2011 16:01:15 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:64107] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/B9-21312-A44A77D4 for ; Wed, 09 Mar 2011 11:01:15 -0500 Received: by vws10 with SMTP id 10so588860vws.29 for ; Wed, 09 Mar 2011 08:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gVaN1JIGJ6zSM/f5aZW96Kxi5xwysJzVUpxj3I2Zc3g=; b=Zq4nhV2c9eI97A8+cMaljVgi4gsRb4rk5nBTmwz+SNYMYdyYoQl7HyGcemxlIt1mQX brPuQ0ZwPC+eki5sOuU0rcKPssmyOkV2ZUT9f3Fg4fax0jCiFV5skNxL3j2b0TNLPEFt zGoC4FlX7bOplUjs0mbhmPUr8+tTDzN/Z4f3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=h5+4Btf/1BTjQuYXNCGoi7xCFHJjPMES3NCbZdrk4tmOwbbys+84rWh3DlSVDXJXZI M9f0sv01fMty4ocX3Kb7vqqG/feBOXeYvNyLQgylwbQeQ+HPXE00H9Ffnu4dMhKvJ+3s ruKR4WRs9HKWOROrkyNrbF4EfBLLY3gV+/0sk= MIME-Version: 1.0 Received: by 10.52.68.168 with SMTP id x8mr7307968vdt.158.1299686470704; Wed, 09 Mar 2011 08:01:10 -0800 (PST) Sender: tyra3l@gmail.com Received: by 10.52.161.227 with HTTP; Wed, 9 Mar 2011 08:01:10 -0800 (PST) In-Reply-To: References: <4D7629B5.4090007@php.net> <4D76D849.6000103@gmail.com> <4D778E63.2060504@gmail.com> Date: Wed, 9 Mar 2011 17:01:10 +0100 X-Google-Sender-Auth: _0QtynHLNVytGa1J3RCK3n72R5I Message-ID: To: Hannes Landeholm Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=20cf307f3bb867dfd8049e0ed6e0 Subject: Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error From: info@tyrael.hu (Ferenc Kovacs) --20cf307f3bb867dfd8049e0ed6e0 Content-Type: text/plain; charset=UTF-8 tyrael@devel-tyrael:~/c$ php -f fatal.php PHP Fatal error: Call to a member function bar() on a non-object in /home/tyrael/c/fatal.php on line 9 PHP Stack trace: PHP 1. {main}() /home/tyrael/c/fatal.php:0 Houston we have a problem: Array ( [type] => 1 [message] => Call to a member function bar() on a non-object [file] => /home/tyrael/c/fatal.php [line] => 9 ) as I mentioned, it works. Tyrael On Wed, Mar 9, 2011 at 4:59 PM, Hannes Landeholm wrote: > No you can't gracefully handle all fatal errors. The shutdown function will > be called after *some* fatal errors but not all of them. See the bug I > reported here for more information: http://bugs.php.net/bug.php?id=54195 > > ~Hannes > > > On 9 March 2011 16:12, Ferenc Kovacs wrote: > >> FYI you can gracefully handle every error. even the non-recoverable ones. >> if you check my library you can test it also, I have an example file for >> every non recoverable error (E_PARSE, E_CORE_ERROR, etc.). >> >> from my point of view, every userland error should be catchable from >> userland. >> the max execution time servers two purpose: >> - it saves you from shooting you in the leg (will abort an infinite loop >> for example) >> - it could be used as a tool by the sysadmin to restrict the cpu usage in >> a shared hosting environment. >> the ability to execute code via register_shutdown_function after the >> "Maximum execution time exceeded" fatal error thrown by the engine makes the >> second point void (except if you disable the register_shutdown_function, >> which you would do of course in a shared environment). >> >> so I think that it should be only used for the first problem, in which >> case it could be catchable IMO, because it doesn't leave the engine in an >> unstable state. >> >> Tyrael >> >> On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm wrote: >> >>> That's not a problem. Timeouts should be non-recoverable IMO as it's a >>> serious problem and I think most PHP developers would agree with this. >>> Making errors "recoverable" is difficult to implement, could have >>> performance penalties and be conceptually wrong when the state is defined as >>> "never allowed to happen". >>> >>> What I'm concerned about is that all problems should be able to be >>> handled gracefully from the register_shutdown_function like showing an >>> informative page, setting HTTP status, logging the problem, sending an error >>> report, etc. Not all fatal errors can be caught this way, including script >>> timeout. >>> >>> ~Hannes >>> >>> >>> On 9 March 2011 15:39, Ferenc Kovacs wrote: >>> >>>> no, it only means that you cant return to the original scope and >>>> continue the execution of your script. >>>> as you can't throw exceptions also, because your code is running without >>>> a stack frame. >>>> you can check out the https://github.com/Tyrael/php-error-handler its a >>>> little class which operates with register_shutdown_function to allow >>>> handling non-recoverable errors before halting. >>>> there are too many case in the php src where non-recoverable errors are >>>> triggered for non fatal problems. >>>> that should be changed, so open a bugreport if you think you found one, >>>> where isn't neccessary to halt the execution. >>>> >>>> Tyrael >>>> >>>> >>>> On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm wrote: >>>> >>>>> You mean the shutdown function is called and 1 nanosecond later PHP >>>>> crashes >>>>> so you don't have time to do anything? >>>>> >>>>> ~Hannes >>>>> >>>>> On 9 March 2011 15:27, David Muir wrote: >>>>> >>>>> > Hmm, I think I worded that poorly. >>>>> > A function registered with register_shutdown_function does execute >>>>> when >>>>> > the max_execution_time is exceeded. >>>>> > What it doesn't let you do is to recover in the same way an error >>>>> > handler would let you. >>>>> > >>>>> > David >>>>> > >>>>> > On 09/03/11 22:56, Hannes Landeholm wrote: >>>>> > > I second making time limit reached catchable. All non catchable >>>>> fatal >>>>> > errors >>>>> > > are a problem for me. I need to handle problems gracefully to >>>>> ensure the >>>>> > > stability of production systems instead of PHP just killing itself >>>>> > without >>>>> > > warning. I just reported a similar issue: >>>>> > > http://bugs.php.net/bug.php?id=54195 >>>>> > > >>>>> > > A simple way to implement this would be to register a function that >>>>> would >>>>> > be >>>>> > > called N seconds before the script would timeout. >>>>> > > >>>>> > > register_timeout_handler(2, function() { die("PHP timed out."); }); >>>>> > > >>>>> > > It would be called just as a shutdown function - in fact I'd like >>>>> to use >>>>> > the >>>>> > > same function as my shutdown function and get the error with >>>>> > > error_get_last(). Of course set_time_limit(0) could be used in this >>>>> > function >>>>> > > to prevent the timeout of the timeout handler. This does not >>>>> "prevent" >>>>> > > timeout since set_time_limit could have been called by the script >>>>> before >>>>> > the >>>>> > > timeout anyway. >>>>> > > >>>>> > > On that note I also miss a function which returns the time the >>>>> script can >>>>> > > keep running for. If that calculate needs to be calculated to >>>>> implemented >>>>> > to >>>>> > > implement this, why not make the value available to the PHP script? >>>>> > > >>>>> > > ~Hannes >>>>> > > >>>>> > > On 9 March 2011 02:30, David Muir wrote: >>>>> > > >>>>> > >> Although it doesn't let you recover from a timeout, you could use >>>>> > >> register_shutdown_function to gracefully exit after a fatal error. >>>>> > >> >>>>> > >> register_shutdown_function(function(){ >>>>> > >> $error = error_get_last(); >>>>> > >> if($error && $error['type'] === E_ERROR){ >>>>> > >> echo 'PHAIL! Oh noes, something went wrong!'; >>>>> > >> // do whatever else you need to do before quitting >>>>> > >> } >>>>> > >> }); >>>>> > >> >>>>> > >> Cheers, >>>>> > >> David >>>>> > >> >>>>> > >> On 08/03/11 22:39, Pierre Joye wrote: >>>>> > >>> hi, >>>>> > >>> >>>>> > >>> is not the goal of this setting to prevent that a script runs >>>>> longer >>>>> > >>> than a given time? A catchable error will prevent that to happen. >>>>> > >>> >>>>> > >>> On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann < >>>>> sebastian@php.net> >>>>> > >> wrote: >>>>> > >>>> Could set_time_limit() be changed in such a way that it >>>>> triggers a >>>>> > >>>> catchable fatal error instead of a fatal error? Thanks! >>>>> > >>>> >>>>> > >>>> -- >>>>> > >>>> Sebastian Bergmann Co-Founder and Principal >>>>> > >> Consultant >>>>> > >>>> http://sebastian-bergmann.de/ >>>>> > >> http://thePHP.cc/ >>>>> > >>>> -- >>>>> > >>>> PHP Internals - PHP Runtime Development Mailing List >>>>> > >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> > >>>> >>>>> > >>>> >>>>> > >>> >>>>> > >> >>>>> > >> -- >>>>> > >> PHP Internals - PHP Runtime Development Mailing List >>>>> > >> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> > >> >>>>> > >> >>>>> > >>>>> > >>>>> > -- >>>>> > PHP Internals - PHP Runtime Development Mailing List >>>>> > To unsubscribe, visit: http://www.php.net/unsub.php >>>>> > >>>>> > >>>>> >>>> >>>> >>> >> > --20cf307f3bb867dfd8049e0ed6e0--