Op 22-3-2010 17:51, Sufficool, Stanley schreef:
-----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...
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
