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