Req #52761 [Com]: include backtrace in web server log on fatal error
| From: | willem at stuursma dot name | Date: | Tue, 24 Jul 2012 11:42:26 +0000 |
| Subject: | Req #52761 [Com]: include backtrace in web server log on fatal error | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-172203@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=52761&edit=1
ID: 52761
Comment by: willem at stuursma dot name
Reported by: freeman3 at centrum dot cz
Summary: include backtrace in web server log on fatal error
Status: Not a bug
Type: Feature/Change Request
Package: Apache2 related
Operating System: opensuse
PHP Version: 5.3.3
Block user comment: N
Private report: N
New Comment:
You can also use the APM extension, which will log all errors with their requests
and stack traces to a database (including E_ERRORs). Still, should be fixed.
Previous Comments:
------------------------------------------------------------------------
[2012-06-07 09:31:40] jl235 at kent dot ac dot uk
It is currently *impossible* to get a backtrace in pure PHP.
Fatal errors by their very definition, are pretty damn serious. A backtrace makes them easier to
debug.
If not add a stack trace to the log, at least allow it to be recorded, and retrieved by user code in
'register_shutdown_function'. Then users can chose to log it themselves.
------------------------------------------------------------------------
[2012-01-10 19:09:43] freeman3 at centrum dot cz
Still no response?
this feature would be very useful. I can't use xdebug in production environment...
is this some zend server only feature?
------------------------------------------------------------------------
[2012-01-10 16:19:00] walovaton at yahoo dot com dot mx
If you install xdebug you will get exactly what you want although it will make the execution
somewhat slower (acceptable in development but maybe not in production).
What I would like to see is a way to get a backtrace of the current point of execution in the PHP
code in a similar way you get it from Java when you kill -3 the process ID. It doesn't die,
instead it gives you a backtrace of what it's doing at that moment. Is there any way to do
this?? I guess I should file a new enhancement request.
------------------------------------------------------------------------
[2011-02-20 21:31:04] freeman3 at centrum dot cz
I totally agree with robin, i still don't get why it's marked as bogus. How do you trace
fatal errors?
I you use a framework and an error occurs in a framework code file (like modelAbstract.php, which
almost every other file uses), the error message like fatal error occured in modelAbstract.php is
totally useless
------------------------------------------------------------------------
[2010-11-04 20:11:23] robin at robindaugherty dot net
"if you want you can implement your error logger in user space"
I don't believe it's possible to implement an error logger for fatal errors in user space.
I see this as a huge problem. I develop and run a
large site using PHP. I have a user-space handler for all other errors, notices, etc., but fatal
errors are uncatchable and the log entry is
usually missing enough information to track down the problem. For example:
Fatal error: ob_start(): Cannot use output buffering in output buffering display handlers in
[...]/ErrorHandler.php on line 785
I've tried to find a way to detect this, and having the backtrace would help. This particular
code is called to render hundreds of variable
on the page before the fatal one (which is apparently a non-fatal error or notice occurring inside
of ob_gzhandler). I just need the call
stack that exists when the error occurs.
This is especially true of production sites, where I try to get enough information to at least
reproduce issues. I get backtraces and
context information for non-fatal errors, but the fatal errors are more important.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=52761
--
Edit this bug report at https://bugs.php.net/bug.php?id=52761&edit=1