Req #52761 [Bgs]: include backtrace in web server log on fatal error
| From: | freeman3 at centrum dot cz | Date: | Sun, 20 Feb 2011 20:31:04 +0000 |
| Subject: | Req #52761 [Bgs]: include backtrace in web server log on fatal error | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-158908@lists.php.net to get a copy of this message | ||
Edit report at http://bugs.php.net/bug.php?id=52761&edit=1
ID: 52761
User updated by: freeman3 at centrum dot cz
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:
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
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2010-09-01 18:11:05] giorgio dot liscio at email dot it
i think this will marked as "wont fix"
full backtrace will be too long to log..
if you want you can implement your error logger in user space
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=52761
--
Edit this bug report at http://bugs.php.net/bug.php?id=52761&edit=1