Sufficool, Stanley wrote:
-----Original Message-----
From: Jille Timmermans [mailto:ji...@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:ji...@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...

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.

As far as coredumps: Security, where would the file be located? Who on the 
server would be able to read it?

I tend to believe some of the issues mentioned can be approached with userland code. I have written a post about catching fatal errors with a little trick including the error context.

I do not really endorse this approach anymore. As Johannes pointed out earlier the Engine enters an unstable state and every action that is done might only worsen the situation and thus even possibly end in, for example, a segfault.

Should monitoring of errors be needed then it might be interesting to aggregate the server logs and filter out PHP errors. There are software bundles who assist in this.

For those interested in the posting, it can be found here: http://blog.naenius.com/2008/05/errorhandling-in-php-now-with-fatal-errors-included/

(My apologies for the singleton ;))
-- Jille
-- Jille

johannes





--
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

Reply via email to