RFC: Error Backtraces v2

[ericnorris]

This pull request seeks to continue the work from #5642, but using an implementation more in line with what nikic suggested in https://externals.io/message/110302#113264:

To put my feedback into more actionable form: Rather than adding an ini
setting that enables error backtraces for all diagnostics, I'd make it a
mask of error types for which a backtrace should be captured, and default
it to fatal errors only. So error_reporting=E_ALL,
error_backtrace=E_ERROR|E_CORE_ERROR|E_COMPILE_ERROR|E_USER_ERROR|E_RECOVERABLE_ERROR|E_PARSE.
It might be handy to expose the internal E_FATAL_ERRORS constant we have
for that.

I think this should give a very sensible default behavior, and people who
want to capture backtraces for all errors still have an option to do so.

Finally, I'm wondering if the backtrace in error_get_last() shouldn't be in
array form, rather than string form.

The RFC will be at https://wiki.php.net/rfc/error_backtraces_v2.

I've created a new INI setting, error_backtrace_recording, which users can set to an error mask to enable backtraces for those errors. It defaults to E_FATAL_ERRORS, which I've also exposed as a userland constant.

Considering the default, any fatal error will now have a backtrace associated with it. For example, a script timeout will now look like:

Fatal error: Maximum execution time of 1 second exceeded in example.php on line 23
Stack trace:
#0 example.php(23): usleep(10000)
#1 example.php(24): recurse()
#2 example.php(24): recurse()
...

This would have been useful to us very recently: we had an issue in production that presented as "Maximum execution time of X second exceeded" errors, and it was difficult for us to identity the underlying culprit. We eventually identified it as an infinite loop, which would have been incredibly obvious in a trace if it was available.

The implementation respects the zend.exception_ignore_args INI setting and the SensitiveParameter attributes, so users can ensure that sensitive arguments do not end up in the backtrace.

I have some open questions about this implementation:

• Why is zend_startup responsible for setting EG(error_reporting), and not executor_globals_ctor? I've done the same for EG(error_backtrace_recording) purely for consistency.
• Is there any appetite for modifying the signature of zend_error_cb? If so, I could pass the backtrace as a nullable argument instead of setting an executor global.

I've updated all tests that are now failing due to the stack trace in the second commit, to keep the diff reviewable.

[ericnorris]

Apologies for the additional notifications, there are understandably quite a lot of tests that trigger fatal errors.

[bukka]

I really don't like the amount of changed files. The default for test runner should be to not display it IMHO.

[NattyNarwhal]

I really don't like the amount of changed files. The default for test runner should be to not display it IMHO.

It is unfortunate; I have a similar feature I was working on that changed error output and the amount of tests it involved touching was really annoying, both to update tests and to review.

[bwoebi]

Can you please add error_backtrace_recording=0 to $ini_overwrites in run-tests.php (and revert most of the phpt changes) - it's generally just noise in all tests.

[ericnorris]

Can you please add error_backtrace_recording=0 to $ini_overwrites in run-tests.php (and revert most of the phpt changes) - it's generally just noise in all tests.

I'll take that into consideration - I'm waiting on the RFC discussion and potential vote before making any further changes at this time. Please chime in there if you have any other thoughts on this proposal, I'd appreciate it!

That said, I've kept the changes to a separate commit, which should allow people to review the first commit in isolation without needing to go through the changed tests. I don't really feel strongly here, however, so if people either want this to default to off (which is a voting option), or just to default to off for tests (which we could decide in the implementation), I'm fine with making the change once we've moved further along in the discussion.

[derickr]

I'll add that I am also not in favour of changes to alllll the tests. I would also add, that the PHP project does not prefix their commit messages with feat: etc.

[iluuu1994]

Not a huge fan of the code churn. IMO, the stack trace should be avoided for compile errors, where the trace is really just noise.

[ericnorris]

Apologies for bumping this PR again - I'm going to look into backporting this internally as I assume the code won't change at this point - but any chance this could get merged sometime this week?

[ndossche]

Maybe @iluuu1994 or @dstogov still have comments, but I don't see problems anymore.

[dstogov]

I don't like the RFC, but it's accepted and I don't see technical problems in the implementation.

[ericnorris]

Hey @dstogov, thanks for taking a look! If you don't like the RFC, would you mind elaborating on what about it you don't like, either privately at my email address, or here? I have some interest in thinking more about error handling and formatting, although I'm happy this RFC at least solves the initial problem I aimed to solve. I'll note that I shared some thoughts on changing how the error callback works in https://externals.io/message/126110#126121, but I didn't get any follow-up discussion to that.

[TimWolla]

I just merged the latest master and added NEWS/UPGRADING. Will merge once the CI passes.

[TimWolla]

Now merged. Don't forget to adjust the status in the Wiki.

[ericnorris]

Thanks @TimWolla, and done.

I appreciate everyone's feedback, and again, if you have additional thoughts on error handling, feel free to reach out to me.

[remicollet]

php.ini not updated