31

I have configured php to log errors and on my development machine, they show up in the apache error logs as:

[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Parse error:  syntax error, unexpected ')' in /Users/troelskn/Projects/test/bootstrap.inc.php on line 27
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Stack trace:
[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP   1. {main}() /Users/troelskn/Projects/test/public/index.php:0

However, on the production machines (Ubuntu) there is no stacktrace following the error and there is a referrer attached to the message. Eg. it would look like:

[Thu Mar 17 18:22:07 2011] [error] [client ::1] PHP Parse error:  syntax error, unexpected ')' in /Users/troelskn/Projects/test/bootstrap.inc.php on line 27, referer: http://localhost/

How can I control this formatting? I would very much like to have the stacktrace available in the logs.

troelskn
  • 115,121
  • 27
  • 131
  • 155
  • 5
    Take a look on this http://stackoverflow.com/questions/3224809/is-there-a-php-ini-directive-that-enables-stack-traces-on-errors – Elzo Valugi Mar 18 '11 at 09:34
  • @elzo You're quite right - the trace comes from xdebug indeed. Can you make this an answer, so I can accept it? – troelskn Mar 18 '11 at 09:45
  • Can you give a link on how to log php stacktraces in apache logs? – side2k Jul 06 '12 at 09:04
  • @side2k The stack traces comes from xdebug. If you install that extension, you'll get traces for free. – troelskn Jul 06 '12 at 10:12
  • @troelskn It's already installed, but I don't see any "save traces to.."-like setting in xdebug docs. – side2k Jul 06 '12 at 14:22
  • Unless something changed in recent versions, it's per default. See [this](http://xdebug.org/archives/xdebug-general/1557.html) – troelskn Jul 06 '12 at 14:34

2 Answers2

20

Well, as has already been pointed out, you're not getting the same formatting on the live machine because the live machine hasn't got xdebug installed. There is debug_backtrace but that wouldn't catch a fatal error.

You could install xdebug on the live server, but you'd have to be very careful to configure it to expose no functionality except for the stack trace logging. Incautious use of xdebug on a live box could pose a security risk as people could initiate a remote debug session, or its enhanced error messages could inadvertently echo out internal details of your code.

To be honest? I'd think your best option is to try and recreate the circumstances under which the error the live server logged occurred on your test server.

EDIT TO ADD: Forgot to mention that in addition to being a security risk, xDebug will also have a negative impact on your website's performance. It hooks into Zend Engine in several crucial ways to log programme state and alter its behaviour (such as overriding @ error suppression), and this will have an inevitable impact on performance. You're basically far better off trying to replicate the issue on a testing environment than you are adding debugging tools to a live one.

GordonM
  • 31,179
  • 15
  • 87
  • 129
  • 1
    Additional comment: XDEBUG with profiling turned on will be extra nasty for performance, and will clutter your server's disk also. I've seen a server crash with exhausted disk space (it was a VM) because a careless admin turned that on. – pgr May 02 '17 at 12:15
1

You can trace by using debug_backtrace or debug_print_backtrace though I never used them. Best tracing come from from xdebug or Zend debugger. I agree with Gordon that you should not install a debugger on a production machine.

Lukasz Czerwinski
  • 13,499
  • 10
  • 55
  • 65
Elzo Valugi
  • 27,240
  • 15
  • 95
  • 114
  • 1
    I don't think this works, because the [call stack isn't passed to `register_shutdown_function()`](https://stackoverflow.com/questions/1448510/how-can-i-get-the-call-stack-from-a-fatal-error#comment5386493_1449568), which AFAIK is the only way to catch fatals. – Ian Dunn May 17 '22 at 15:40