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] johan...@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

Reply via email to