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

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.

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

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.

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

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

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.

Still no response?
this feature would be very useful. I can't use xdebug in production environment...
is this some zend server only feature?

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.

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.