Edit report at https://bugs.php.net/bug.php?id=52761&edit=1
ID: 52761
Comment by: walovaton at yahoo dot com dot mx
Reported by: freeman3 at centrum dot cz
Summary: include backtrace in web server log on fatal error
Status: Bogus
Type: Feature/Change Request
Package: Apache2 related
Operating System: opensuse
PHP Version: 5.3.3
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2010-09-01 22:52:15] freeman3 at centrum dot cz
I know it's not a bug. That's why I marked it as feature request (where else
should I post feature request?!?). And I didn't find such option in php manual. I
wanted only extend the error message in the log, I don't want to install xdebug
on production server...
I still think it would be a good idea.
------------------------------------------------------------------------
[2010-09-01 21:30:41] johannes@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
You can install xdebug on your development server to get this feature. http://xdebug.org
------------------------------------------------------------------------
[2010-09-01 19:01:23] freeman3 at centrum dot cz
Too long? I mean log only for fatal error and such. I happens only when developing application
usually, few times a day. It would be few extra lines only. Access log has several GB usually so I
think few lines doesn't matter. I think many developers would be grateful because this can save
much time.
I have tried something with shutdown handler but it didn't work for me. If you have a code that
returns backtrace when fatal error occurs, I would be grateful.
------------------------------------------------------------------------
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