Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51645 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36335 invoked from network); 9 Mar 2011 16:13:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2011 16:13:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=landeholm@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=landeholm@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: landeholm@gmail.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:61480] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 77/4A-21312-727A77D4 for ; Wed, 09 Mar 2011 11:13:28 -0500 Received: by iyb12 with SMTP id 12so694699iyb.29 for ; Wed, 09 Mar 2011 08:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AUxu5RMErb5r3XAoM7YUElAsvvikRgS3AjXCKMTO+7k=; b=JHX4WNSB4EyXhayXCdzTnBdow61xEkk//PIpir3FImjAKH9eWmmdqW1kUjysEg9gvV 6/ehH1j8DnmpKxE5OuSnea4IzNde6nhWpNdtcfiWTGF2WmonDqVy0O96Cn2vT5E/7ZbG 9GjCB0E1ldUvq76Jwxrf+sgojc+OM5iCPZ1fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=f9xSljJt2nHRhEzbBk4STxKzTny6k1jKSEGhuh7BBjBlgWUUYzt/X0ORaKmA9gskJI tea5wGiadFcnDQA1iBm1upRDBJpO84bBPG9rzCci+ydPnlk9RayItUguF6lU0Ds2qswI 3TcfxC1JVCg9XoRMX29E7b4JoQ5LLhAKYWJL4= MIME-Version: 1.0 Received: by 10.43.59.130 with SMTP id wo2mr6353893icb.88.1299687204457; Wed, 09 Mar 2011 08:13:24 -0800 (PST) Received: by 10.231.17.68 with HTTP; Wed, 9 Mar 2011 08:13:24 -0800 (PST) In-Reply-To: References: <4D7629B5.4090007@php.net> <4D76D849.6000103@gmail.com> <4D778E63.2060504@gmail.com> Date: Wed, 9 Mar 2011 17:13:24 +0100 Message-ID: To: Ferenc Kovacs , internals@lists.php.net Content-Type: multipart/alternative; boundary=bcaec51dd30f240e6e049e0f0214 Subject: Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error From: landeholm@gmail.com (Hannes Landeholm) --bcaec51dd30f240e6e049e0f0214 Content-Type: text/plain; charset=ISO-8859-1 Yes.. apparently it works. My mistake. I accidentally tested it in a context with error suppression enabled. Apparently there where some other reason for it not being gracefully caught in production then. Going to have an extra look at it. Closing the bug in the meantime. ~ Hannes On 9 March 2011 17:01, Ferenc Kovacs wrote: > 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 >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> > --bcaec51dd30f240e6e049e0f0214--