Re: [PATCH] Raise warning first on "Maximum execution time exceeded"

Op 22-3-2010 17:14, Sufficool, Stanley schreef:

-----Original Message----- From: Jille Timmermans [mailto:jille@quis.cx] Sent: Monday, March 22, 2010 8:44 AM To: Johannes Schlüter Cc: troels knak-nielsen; PHP Developers Mailing List Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time exceeded" Op 22-3-2010 16:14, Johannes Schlüter schreef:

     
On Mon, 2010-03-22 at 15:51 +0100, troels knak-nielsen wrote:

       
We log all errors that happens in our production
         

environment, but as

fatal errors can't be handled from within php, we end up

with little

information to go on for further debugging. I'm not very familiar with the php internals code, but I managed to throw in a hack that appears to work. In the handler function for timeouts

(zend_timeout),

I raise a WARNING, sleep for 1 second and then resume normal behavior, which results in a fatal error. This gives

userland code 1

second to log the error somewhere, which should be sufficient for debugging.

A one second delay is no option there. And what actually happens is that the warning triggers your custom error handler. After that it sleeps then it dies. This also creates a "nice" way to extend the script runtime

after the

timeout occurred. aka. making the timeout useless for many

scenarios

it was meant for.

This could be made configurable. Shared hosting providers probably want to disable the 'overriding' of the timeout. At my work; all code is written by our own developers; so there's no evil in there ;) (And it would be usefull to give extra debugging information)

Think outside the engine. The engine dies with a fatal error, set a handler to run another PHP instance. The engine then passes the error object as serialized argv to the handler. set_fatal_handler("fatal_handler.php"); I don't a practical way to continue script execution in any way without causing some issue. The service provider should be able to kill this with a custom error handler set in INI. fatal_handler="mail_fatal.sh" #Log / mail using our script fatal_handler="" # (default) - Don't allow user override #fatal_handler="" # handler undefined / Allow override You can already do that from the shutdown functions. They run even after fatal errors. php -r 'register_shutdown_function(function() { echo "bye"; }); ohcrap();' But the most common request is a backtrace; which can not be generated from the shutdown function; neither from an external script. ("Hey! We could use coredumps for this! That allows post-mortem examination by some external error handler!") -- Jille

-- Jille

     
johannes

-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php