Drupal 7 and 8 are quite a lot more likely to be interrupted by a fatal that just gives nearly no information at all to the user/administrator. We've seen these throughout Drupal's history, but there seem to be more of them now that various exceptions can halt Drupal (it's quite a lot less forgiving, for better or worse, in D7/D8).
But as pointed out in the deep past in webchick's outstanding Quick and Dirty Debugging there is something we can do about this. The presentation of debug_backtrace() at least gives some clue about what's going on, and can make the issue queue discussion of a problem far more effective. But why should one have to hack core to get that information? Why don't we just provide it in the log?
This patch simply provides a debug_backtrace() in the error log if the error is fatal and suggests to the poor user that they can look there.
Note that DBTNG in D7/D8 does a pretty good job of analyzing a backtrace and actually provides the location of the error. I'd love if we could do this everywhere, but I don't think we can; DBTNG just has a very structured understanding of how it might be called.
I note to webchick's glee that this broke my resolution not to install a D8 site.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | drupal.d8_backtrace_in_fatal_error_log_1157850_02.patch | 1.81 KB | rfay |
| drupal.backtrace_in_fatal_error_log.patch.d7.txt | 1.81 KB | rfay | |
| drupal.d8_backtrace_in_fatal_error_log.patch | 1.81 KB | rfay |
Comments
Comment #1
chx commentedPlease use var_dump and not print_r. The often crucial pieces FALSE/NULL/empty strings do not show with print_r. Also did you experiment with debug_print_backtrace
Comment #2
rfayOK, here it is with var_export().
Comment #3
webchickBack in #168812: Add useful error reporting for db_query() (or add backtraces to watchdog) when I worked on a patch in D6 to actually print the fricking query instead of "such and such error on line XXX of mysql.inc", one of the versions I did included this. It was crashing my browser trying to load all of the details for the backtrace. So we might want to limit this to some special 'debug' mode only, not sure. Or at least try testing it with a number of different error conditions including recursion recursion recursion recursion. ;)
Comment #4
webchickAlso, this can't be backported to D7 without breaking strings, unfortunately.
Comment #5
rfayI can do this without breaking strings... But it would just be slightly different. The only string this changes in D8 (I think) is the one that tells the user there's more stuff in the log. So this is displayed only when you look at the detail of an error message in the log.
@webchick: They *did* get an outstanding DBTNG error reporter into D7, which has complete information about the query and the line it was *actually* called from. Which is fantastic. One of the many hidden beauties of D7.
Comment #6
damien tournoud commentedMost probably we need to remove the objects from there (at least the 'object' key), and I think we should just print a simplified backtrace here. The exception backtrace also needs to use
->getTrace().Comment #7
rfay@Damien, can you give me some guidance on why to remove the object key, or objects?
Comment #8
damien tournoud commentedDuplicate of #1158322: Add backtrace to all errors, which has a better patch, IMO.
Comment #9
rooby commented