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!")
-- 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
