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

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

-----Original Message----- From: Jille Timmermans [mailto:jille@quis.cx] Sent: Monday, March 22, 2010 9:30 AM To: Sufficool, Stanley Cc: 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] [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!")

     But with register_shutdown_function you do not have an error context right? If the user is doing something with the error, they will need the file, line, message, etc...
   error_get_last();

Also does register_shutdown_function work with max_execution_time, out of memory, compile error, etc...? I'm really thinking that for a complete fatal handler function to work, it needs to execute a known good handler script outside of the offending code. I agree; but I was trying to point out that it doesn't need to be an external handler.

As far as coredumps: Security, where would the file be located? Who on the server would be able to read it? It was a joke ;)

-- Jille

-- Jille

     
       
-- Jille

         
johannes

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