wiki.techinc.nl/includes/exception/MWExceptionHandler.php

770 lines
24 KiB
PHP
Raw Normal View History

<?php
/**
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
*/
use MediaWiki\Logger\LoggerFactory;
use MediaWiki\MediaWikiServices;
use Psr\Log\LogLevel;
use Wikimedia\NormalizedException\INormalizedException;
use Wikimedia\Rdbms\DBError;
use Wikimedia\Rdbms\DBQueryError;
/**
* Handler class for MWExceptions
* @ingroup Exception
*/
class MWExceptionHandler {
/** @var string Error caught and reported by this exception handler */
public const CAUGHT_BY_HANDLER = 'mwe_handler';
/** @var string Error caught and reported by a script entry point */
public const CAUGHT_BY_ENTRYPOINT = 'entrypoint';
/** @var string Error reported by direct logException() call */
public const CAUGHT_BY_OTHER = 'other';
/** @var string */
protected static $reservedMemory;
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
/**
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
* Error types that, if unhandled, are fatal to the request.
* These error types may be thrown as Error objects, which implement Throwable (but not Exception).
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
*
* The user will be shown an HTTP 500 Internal Server Error.
* As such, these should be sent to MediaWiki's "exception" channel.
* Normally, the error handler logs them to the "error" channel.
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
*
* @var array
*/
protected static $fatalErrorTypes = [
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
E_ERROR,
E_PARSE,
E_CORE_ERROR,
E_COMPILE_ERROR,
E_USER_ERROR,
// E.g. "Catchable fatal error: Argument X must be Y, null given"
E_RECOVERABLE_ERROR,
];
/**
* Install handlers with PHP.
*/
public static function installHandler() {
// This catches:
// * Exception objects that were explicitly thrown but not
// caught anywhere in the application. This is rare given those
// would normally be caught at a high-level like MediaWiki::run (index.php),
// api.php, or ResourceLoader::respond (load.php). These high-level
// catch clauses would then call MWExceptionHandler::logException
// or MWExceptionHandler::handleException.
// If they are not caught, then they are handled here.
// * Error objects for issues that would historically
// cause fatal errors but may now be caught as Throwable (not Exception).
// Same as previous case, but more common to bubble to here instead of
// caught locally because they tend to not be safe to recover from.
// (e.g. argument TypeError, division by zero, etc.)
set_exception_handler( 'MWExceptionHandler::handleUncaughtException' );
// This catches recoverable errors (e.g. PHP Notice, PHP Warning, PHP Error) that do not
// interrupt execution in any way. We log these in the background and then continue execution.
set_error_handler( 'MWExceptionHandler::handleError' );
// This catches fatal errors for which no Throwable is thrown,
// including Out-Of-Memory and Timeout fatals.
// Reserve 16k of memory so we can report OOM fatals.
self::$reservedMemory = str_repeat( ' ', 16384 );
register_shutdown_function( 'MWExceptionHandler::handleFatalError' );
}
/**
* Report a throwable to the user
* @param Throwable $e
*/
protected static function report( Throwable $e ) {
try {
// Try and show the exception prettily, with the normal skin infrastructure
if ( $e instanceof MWException ) {
// Delegate to MWException until all subclasses are handled by
// MWExceptionRenderer and MWException::report() has been
// removed.
$e->report();
} else {
MWExceptionRenderer::output( $e, MWExceptionRenderer::AS_PRETTY );
}
} catch ( Throwable $e2 ) {
// Exception occurred from within exception handler
// Show a simpler message for the original exception,
// don't try to invoke report()
MWExceptionRenderer::output( $e, MWExceptionRenderer::AS_RAW, $e2 );
}
}
/**
* Roll back any open database transactions and log the stack trace of the throwable
*
* This method is used to attempt to recover from exceptions
*
* @since 1.37
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
*/
public static function rollbackPrimaryChangesAndLog(
Throwable $e,
$catcher = self::CAUGHT_BY_OTHER
) {
$services = MediaWikiServices::getInstance();
if ( !$services->isServiceDisabled( 'DBLoadBalancerFactory' ) ) {
// Rollback DBs to avoid transaction notices. This might fail
// to rollback some databases due to connection issues or exceptions.
// However, any sane DB driver will rollback implicitly anyway.
try {
$services->getDBLoadBalancerFactory()->rollbackPrimaryChanges( __METHOD__ );
} catch ( DBError $e2 ) {
// If the DB is unreacheable, rollback() will throw an error
// and the error report() method might need messages from the DB,
// which would result in an exception loop. PHP may escalate such
// errors to "Exception thrown without a stack frame" fatals, but
// it's better to be explicit here.
self::logException( $e2, $catcher );
}
}
self::logException( $e, $catcher );
}
/**
* @deprecated since 1.37; please use rollbackPrimaryChangesAndLog() instead.
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
*/
public static function rollbackMasterChangesAndLog(
Throwable $e,
$catcher = self::CAUGHT_BY_OTHER
) {
wfDeprecated( __METHOD__, '1.37' );
self::rollbackPrimaryChangesAndLog( $e, $catcher );
}
/**
* Callback to use with PHP's set_exception_handler.
*
* @since 1.31
* @param Throwable $e
*/
public static function handleUncaughtException( Throwable $e ) {
self::handleException( $e, self::CAUGHT_BY_HANDLER );
// Make sure we don't claim success on exit for CLI scripts (T177414)
if ( wfIsCLI() ) {
register_shutdown_function(
/**
* @return never
*/
static function () {
exit( 255 );
}
);
}
}
/**
* Exception handler which simulates the appropriate catch() handling:
*
* try {
* ...
* } catch ( Exception $e ) {
* $e->report();
* } catch ( Exception $e ) {
* echo $e->__toString();
* }
*
* @since 1.25
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
*/
public static function handleException( Throwable $e, $catcher = self::CAUGHT_BY_OTHER ) {
self::rollbackPrimaryChangesAndLog( $e, $catcher );
self::report( $e );
}
/**
* Handler for set_error_handler() callback notifications.
*
* Receive a callback from the interpreter for a raised error, create an
* ErrorException, and log the exception to the 'error' logging
* channel(s).
*
* @since 1.25
* @param int $level Error level raised
* @param string $message
* @param string|null $file
* @param int|null $line
* @return bool
*/
public static function handleError(
$level,
$message,
$file = null,
$line = null
) {
global $wgPropagateErrors;
// Map PHP error constant to a PSR-3 severity level.
// Avoid use of "DEBUG" or "INFO" levels, unless the
// error should evade error monitoring and alerts.
//
// To decide the log level, ask yourself: "Has the
// program's behaviour diverged from what the written
// code expected?"
//
// For example, use of a deprecated method or violating a strict standard
// has no impact on functional behaviour (Warning). On the other hand,
// accessing an undefined variable makes behaviour diverge from what the
// author intended/expected. PHP recovers from an undefined variables by
// yielding null and continuing execution, but it remains a change in
// behaviour given the null was not part of the code and is likely not
// accounted for.
switch ( $level ) {
case E_WARNING:
case E_CORE_WARNING:
case E_COMPILE_WARNING:
$prefix = 'PHP Warning: ';
$severity = LogLevel::ERROR;
break;
case E_NOTICE:
$prefix = 'PHP Notice: ';
$severity = LogLevel::ERROR;
break;
case E_USER_NOTICE:
// Used by wfWarn(), MWDebug::warning()
$prefix = 'PHP Notice: ';
$severity = LogLevel::WARNING;
break;
case E_USER_WARNING:
// Used by wfWarn(), MWDebug::warning()
$prefix = 'PHP Warning: ';
$severity = LogLevel::WARNING;
break;
case E_STRICT:
$prefix = 'PHP Strict Standards: ';
$severity = LogLevel::WARNING;
break;
case E_DEPRECATED:
debug: Use native E_USER_DEPRECATED instead of custom channel * Always use trigger_error for deprecation warnings, not just in development. They are still silent from the run-time perspective (not thrown as exceptions). Previously this code path was only called when $wgDevelopmentWarnings is set to true. For most dev environments and for CI, this means nothing much changes given that DevelopmentSettings.php set this to true. * In the code path that handles native PHP warnings, when setting the $file and $line attribution that Logstash/Kibana report as "exception.file" use the same offset as the one that wfDeprecated() has computed from the back trace. This means it no longer (wrongly/uselessly) attributes all deprecation warnings to MWDebug.php. * Trim the message suffix from "Called from <method> in <file>" to just "Called from <method>". This reduces noise and makes the message more stable over multiple MW branches. The stack trace is still there like before. == Before (only with $wgDevelopmentWarnings) == > PHP Deprecated: Use of wfGetScriptUrl was deprecated in MediaWiki 1.35. > [Called from MediaWiki::__construct in /var/mediawiki/includes/MediaWiki.php at line 67] > > Error from line 393 of /var/mediawiki/includes/debug/MWDebug.php > > #0 [internal function]: MWExceptionHandler::handleError() > #1 /var/mediawiki/includes/debug/MWDebug.php(393): trigger_error() > #2 /var/mediawiki/includes/debug/MWDebug.php(297): MWDebug::sendMessage() > #3 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated() > #4 /var/mediawiki/includes/GlobalFunctions.php(1032): MWDebug::deprecated() > #5 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated() > #6 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string) > #7 /var/mediawiki/load.php(50): MediaWiki->__construct() == After (always) == > Use of wfGetScriptUrl was deprecated in MediaWiki 1.35. [Called from MediaWiki::__construct] > > Error from line 67 of /var/mediawiki/includes/MediaWiki.php > > #0 [internal function]: MWExceptionHandler::handleError() > #1 /var/mediawiki/includes/debug/MWDebug.php(293): trigger_error() > #2 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated() > #3 /var/mediawiki/includes/GlobalFunctions.php(1038): MWDebug::deprecated() > #4 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated() > #5 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string) > #6 /var/mediawiki/load.php(50): MediaWiki->__construct() Bug: T252923 Change-Id: I1d4a166b6dff8b0e19fce3fab409f4a89e734ee6
2020-05-28 02:14:07 +00:00
$prefix = 'PHP Deprecated: ';
$severity = LogLevel::WARNING;
break;
case E_USER_DEPRECATED:
$prefix = 'PHP Deprecated: ';
$severity = LogLevel::WARNING;
debug: Use native E_USER_DEPRECATED instead of custom channel * Always use trigger_error for deprecation warnings, not just in development. They are still silent from the run-time perspective (not thrown as exceptions). Previously this code path was only called when $wgDevelopmentWarnings is set to true. For most dev environments and for CI, this means nothing much changes given that DevelopmentSettings.php set this to true. * In the code path that handles native PHP warnings, when setting the $file and $line attribution that Logstash/Kibana report as "exception.file" use the same offset as the one that wfDeprecated() has computed from the back trace. This means it no longer (wrongly/uselessly) attributes all deprecation warnings to MWDebug.php. * Trim the message suffix from "Called from <method> in <file>" to just "Called from <method>". This reduces noise and makes the message more stable over multiple MW branches. The stack trace is still there like before. == Before (only with $wgDevelopmentWarnings) == > PHP Deprecated: Use of wfGetScriptUrl was deprecated in MediaWiki 1.35. > [Called from MediaWiki::__construct in /var/mediawiki/includes/MediaWiki.php at line 67] > > Error from line 393 of /var/mediawiki/includes/debug/MWDebug.php > > #0 [internal function]: MWExceptionHandler::handleError() > #1 /var/mediawiki/includes/debug/MWDebug.php(393): trigger_error() > #2 /var/mediawiki/includes/debug/MWDebug.php(297): MWDebug::sendMessage() > #3 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated() > #4 /var/mediawiki/includes/GlobalFunctions.php(1032): MWDebug::deprecated() > #5 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated() > #6 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string) > #7 /var/mediawiki/load.php(50): MediaWiki->__construct() == After (always) == > Use of wfGetScriptUrl was deprecated in MediaWiki 1.35. [Called from MediaWiki::__construct] > > Error from line 67 of /var/mediawiki/includes/MediaWiki.php > > #0 [internal function]: MWExceptionHandler::handleError() > #1 /var/mediawiki/includes/debug/MWDebug.php(293): trigger_error() > #2 /var/mediawiki/includes/debug/MWDebug.php(270): MWDebug::sendRawDeprecated() > #3 /var/mediawiki/includes/GlobalFunctions.php(1038): MWDebug::deprecated() > #4 /var/mediawiki/includes/GlobalFunctions.php(2548): wfDeprecated() > #5 /var/mediawiki/includes/MediaWiki.php(67): wfGetScriptUrl(string) > #6 /var/mediawiki/load.php(50): MediaWiki->__construct() Bug: T252923 Change-Id: I1d4a166b6dff8b0e19fce3fab409f4a89e734ee6
2020-05-28 02:14:07 +00:00
$real = MWDebug::parseCallerDescription( $message );
if ( $real ) {
// Used by wfDeprecated(), MWDebug::deprecated()
// Apply caller offset from wfDeprecated() to the native error.
// This makes errors easier to aggregate and find in e.g. Kibana.
$file = $real['file'];
$line = $real['line'];
$message = $real['message'];
}
break;
default:
$prefix = 'PHP Unknown error: ';
$severity = LogLevel::ERROR;
break;
}
$e = new ErrorException( $prefix . $message, 0, $level, $file, $line );
self::logError( $e, 'error', $severity, self::CAUGHT_BY_HANDLER );
// If $wgPropagateErrors is true return false so PHP shows/logs the error normally.
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
// Ignore $wgPropagateErrors if track_errors is set
// (which means someone is counting on regular PHP error handling behavior).
exception: Report uncaught "Catchable" fatal to "fatal" channel Things like "Catchable fatal error: Must be X, null given" stop execution immediately after the error handler callback, and produce an HTTP 500 Internal Server Error page. They are very fatal. Per <https://secure.php.net/manual/en/language.errors.php7.php>, on PHP 7 this results in a TypeError throwable which will eventually fatal the request and be reported through set_exception_handler, or be caught by our top-level 'catch' and artificially forwarded to our set_exception_handler callback. On HHVM, these fatal error types are PHP5-like in that they don't have a throwable object to throw yet, instead the error meta-data is sent directly as parameeters to set_error_handler, the same as for warnings. We need to intercept them there so that they are reported correctly. Sample from PHP 7: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [no req] TypeError from line 50 of .../MutableRevisionRecord.php: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given, > called in /var/www/mediawiki/maintenance/eval.php(78) ... [exit status: error(255)] Sample from HHVM: > MediaWiki\Storage\MutableRevisionRecord::newFromParentRevision( null ); > [hphp] set_error_handler called with: > ... $type = 4096 // E_RECOVERABLE_ERROR > > [hphp] [...] Catchable fatal error: > Argument 1 passed to ...\MutableRevisionRecord::newFromParentRevision() > must be an instance of MediaWiki\Storage\RevisionRecord, null given > ... [exit status: error(255)] Interestingly, if you forget to return false from set_error_handler for fatal errors on HHVM, it can actually continue execution. Bug: T205677 Change-Id: I18dd2ff37fa2c2679d0c598cbeff0c61c2fe0253
2018-09-27 23:54:39 +00:00
return !( $wgPropagateErrors || ini_get( 'track_errors' ) );
}
/**
* Callback used as a registered shutdown function.
*
* This is used as callback from the interpreter at system shutdown.
* If the last error was not a recoverable error that we already reported,
* and log as fatal exception.
*
* Special handling is included for missing class errors as they may
* indicate that the user needs to install 3rd-party libraries via
* Composer or other means.
*
* @since 1.25
* @return bool Always returns false
*/
public static function handleFatalError() {
// Free reserved memory so that we have space to process OOM
// errors
self::$reservedMemory = null;
$lastError = error_get_last();
if ( $lastError === null ) {
return false;
}
$level = $lastError['type'];
$message = $lastError['message'];
$file = $lastError['file'];
$line = $lastError['line'];
if ( !in_array( $level, self::$fatalErrorTypes ) ) {
// Only interested in fatal errors, others should have been
// handled by MWExceptionHandler::handleError
return false;
}
$url = WebRequest::getGlobalRequestURL();
$msgParts = [
'[{reqId}] {exception_url} PHP Fatal Error',
( $line || $file ) ? ' from' : '',
$line ? " line $line" : '',
( $line && $file ) ? ' of' : '',
$file ? " $file" : '',
": $message",
];
$msg = implode( '', $msgParts );
// Look at message to see if this is a class not found failure (Class 'foo' not found)
if ( preg_match( "/Class '\w+' not found/", $message ) ) {
// phpcs:disable Generic.Files.LineLength
$msg = <<<TXT
{$msg}
MediaWiki or an installed extension requires this class but it is not embedded directly in MediaWiki's git repository and must be installed separately by the end user.
Please see <a href="https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries">mediawiki.org</a> for help on installing the required components.
TXT;
// phpcs:enable
}
$e = new ErrorException( "PHP Fatal Error: {$message}", 0, $level, $file, $line );
$logger = LoggerFactory::getInstance( 'exception' );
$logger->error( $msg, self::getLogContext( $e, self::CAUGHT_BY_HANDLER ) );
return false;
}
/**
* Generate a string representation of a throwable's stack trace
*
* Like Throwable::getTraceAsString, but replaces argument values with
exception: Add the 'from' file/line to the logged exception trace This should make error logs easier to work with through a couple of ways: * The stack trace is now complete, instead of missing the first crucial step, which is often the one used for filtering purposes and for identifying errors within a given deployed version of MediaWiki. (E.g. when filtering out an error that is expected to be fixed by the next release and/or when checking how prominent an error currently is). * Logstash reports that report message + trace will not need to be edited by hand to include the file+line. * The workflow for Logstash generally follows one of two patterns. The default is to filter by exception.file (including line number), which is very sure to catch all possible variants thrown from the same code, regardless of any variables in the message, but has the downside of not matching week-over-week consistency due to file paths (at least for WMF) containing the deployment version. The other option is to filter by message, which has the risk of possibly excluding too much if there are multiple unrelated ways to trigger the issue, but is a sensible second option. This is usually done by filtering on normalized_message for non-exception errors, but doesn't work well for exceptions because they contain the file paths and do so in-between the class and message words, and thus are not compatible with Logstash's default substring/term match. The alternative of exception.message is then considered but is lacking the class/type, which can be fragile. With this change applied, no editing is needed, and no multiple approaches need to be considered with the same option. Either filtering by exception.file as-is, or filtering by normalized_message as-is, regardless of whether it is an exception error or other message in another channel, will both work. Bug: T271496 Change-Id: I5908ed53f9b97b3c9cde126aca89ab6fc197c845
2021-01-08 00:15:01 +00:00
* their type or class name, and prepends the start line of the throwable.
*
* @param Throwable $e
* @return string
* @see prettyPrintTrace()
*/
public static function getRedactedTraceAsString( Throwable $e ) {
exception: Add the 'from' file/line to the logged exception trace This should make error logs easier to work with through a couple of ways: * The stack trace is now complete, instead of missing the first crucial step, which is often the one used for filtering purposes and for identifying errors within a given deployed version of MediaWiki. (E.g. when filtering out an error that is expected to be fixed by the next release and/or when checking how prominent an error currently is). * Logstash reports that report message + trace will not need to be edited by hand to include the file+line. * The workflow for Logstash generally follows one of two patterns. The default is to filter by exception.file (including line number), which is very sure to catch all possible variants thrown from the same code, regardless of any variables in the message, but has the downside of not matching week-over-week consistency due to file paths (at least for WMF) containing the deployment version. The other option is to filter by message, which has the risk of possibly excluding too much if there are multiple unrelated ways to trigger the issue, but is a sensible second option. This is usually done by filtering on normalized_message for non-exception errors, but doesn't work well for exceptions because they contain the file paths and do so in-between the class and message words, and thus are not compatible with Logstash's default substring/term match. The alternative of exception.message is then considered but is lacking the class/type, which can be fragile. With this change applied, no editing is needed, and no multiple approaches need to be considered with the same option. Either filtering by exception.file as-is, or filtering by normalized_message as-is, regardless of whether it is an exception error or other message in another channel, will both work. Bug: T271496 Change-Id: I5908ed53f9b97b3c9cde126aca89ab6fc197c845
2021-01-08 00:15:01 +00:00
$from = 'from ' . $e->getFile() . '(' . $e->getLine() . ')' . "\n";
return $from . self::prettyPrintTrace( self::getRedactedTrace( $e ) );
}
/**
* Generate a string representation of a stacktrace.
*
* @since 1.26
* @param array $trace
* @param string $pad Constant padding to add to each line of trace
* @return string
*/
public static function prettyPrintTrace( array $trace, $pad = '' ) {
$text = '';
$level = 0;
foreach ( $trace as $level => $frame ) {
if ( isset( $frame['file'] ) && isset( $frame['line'] ) ) {
$text .= "{$pad}#{$level} {$frame['file']}({$frame['line']}): ";
} else {
// 'file' and 'line' are unset for calls from C code
// (T57634) This matches behaviour of
// Throwable::getTraceAsString to instead display "[internal
// function]".
$text .= "{$pad}#{$level} [internal function]: ";
}
if ( isset( $frame['class'] ) && isset( $frame['type'] ) && isset( $frame['function'] ) ) {
$text .= $frame['class'] . $frame['type'] . $frame['function'];
} elseif ( isset( $frame['function'] ) ) {
$text .= $frame['function'];
} else {
$text .= 'NO_FUNCTION_GIVEN';
}
if ( isset( $frame['args'] ) ) {
$text .= '(' . implode( ', ', $frame['args'] ) . ")\n";
} else {
$text .= "()\n";
}
}
$level++;
$text .= "{$pad}#{$level} {main}";
return $text;
}
/**
* Return a copy of a throwable's backtrace as an array.
*
* Like Throwable::getTrace, but replaces each element in each frame's
* argument array with the name of its class (if the element is an object)
* or its type (if the element is a PHP primitive).
*
* @since 1.22
* @param Throwable $e
* @return array
*/
public static function getRedactedTrace( Throwable $e ) {
return static::redactTrace( $e->getTrace() );
}
/**
* Redact a stacktrace generated by Throwable::getTrace(),
* debug_backtrace() or similar means. Replaces each element in each
* frame's argument array with the name of its class (if the element is an
* object) or its type (if the element is a PHP primitive).
*
* @since 1.26
* @param array $trace Stacktrace
* @return array Stacktrace with arugment values converted to data types
*/
public static function redactTrace( array $trace ) {
return array_map( static function ( $frame ) {
if ( isset( $frame['args'] ) ) {
$frame['args'] = array_map( static function ( $arg ) {
return is_object( $arg ) ? get_class( $arg ) : gettype( $arg );
}, $frame['args'] );
}
return $frame;
}, $trace );
}
/**
* If the exception occurred in the course of responding to a request,
* returns the requested URL. Otherwise, returns false.
*
* @since 1.23
* @return string|false
*/
public static function getURL() {
global $wgRequest;
if ( !isset( $wgRequest ) || $wgRequest instanceof FauxRequest ) {
return false;
}
return $wgRequest->getRequestURL();
}
/**
* Get a message formatting the throwable message and its origin.
*
* Despite the method name, this is not used for logging.
* It is only used for HTML or CLI output, by MWExceptionRenderer
* and MWException::getText, respectively.
*
* @since 1.22
* @param Throwable $e
* @return string
*/
public static function getLogMessage( Throwable $e ) {
Provide a unique request identifier When MediaWiki encounters an unhandled exception, the error message it produces includes a randomly-generated token, which allows the exception details to be looked up in the error logs. This is useful but narrow: would it not be useful to have the ability to retrieve all log records associated with a particular request, rather than just exception details? (Hint: yes.) So: introduce the notion of a request-global unique ID, retrievable via WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id (which provides the same facility) or some other software which sets a UNIQUE_ID envvar, the value of that envvar is used as the request ID. Otherwise, it is a randomly-generated 24-character string. The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId() is deprecated, accordingly. The request ID is also added as an annotation to all Monolog-processed log records, and is exposed client-side as 'wgRequestId'. This allows developers to associate a page view with log records even when the page view does not result in an unhandled exception. (For the WMF, I also intend to add it as an annotation to profiling data). The request ID is not a tracking token; it does not persist, and it is associated with a backend request, not with a particular user or a particular session. Like the data in the NewPP report, the request ID is designed to be cacheable, so that if, for example, a developer notices something weird in the HTML, s/he can associate the output with a backend request regardless of whether the response was served from the cache or directly from the backend. Some prior art: * https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html * http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html * https://github.com/dabapps/django-log-request-id * https://packagist.org/packages/php-middleware/request-id * https://github.com/rhyselsmore/flask-request-id Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
2016-03-25 01:43:23 +00:00
$id = WebRequest::getRequestId();
$type = get_class( $e );
$message = $e->getMessage();
$url = self::getURL() ?: '[no req]';
if ( $e instanceof DBQueryError ) {
$message = "A database query error has occurred. Did you forget to run"
. " your application's database schema updater after upgrading"
. " or after adding a new extension?\n\nPlease see"
. " https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Upgrading and"
. " https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:How_to_debug"
. " for more information.\n\n"
. $message;
}
exception: Add the 'from' file/line to the logged exception trace This should make error logs easier to work with through a couple of ways: * The stack trace is now complete, instead of missing the first crucial step, which is often the one used for filtering purposes and for identifying errors within a given deployed version of MediaWiki. (E.g. when filtering out an error that is expected to be fixed by the next release and/or when checking how prominent an error currently is). * Logstash reports that report message + trace will not need to be edited by hand to include the file+line. * The workflow for Logstash generally follows one of two patterns. The default is to filter by exception.file (including line number), which is very sure to catch all possible variants thrown from the same code, regardless of any variables in the message, but has the downside of not matching week-over-week consistency due to file paths (at least for WMF) containing the deployment version. The other option is to filter by message, which has the risk of possibly excluding too much if there are multiple unrelated ways to trigger the issue, but is a sensible second option. This is usually done by filtering on normalized_message for non-exception errors, but doesn't work well for exceptions because they contain the file paths and do so in-between the class and message words, and thus are not compatible with Logstash's default substring/term match. The alternative of exception.message is then considered but is lacking the class/type, which can be fragile. With this change applied, no editing is needed, and no multiple approaches need to be considered with the same option. Either filtering by exception.file as-is, or filtering by normalized_message as-is, regardless of whether it is an exception error or other message in another channel, will both work. Bug: T271496 Change-Id: I5908ed53f9b97b3c9cde126aca89ab6fc197c845
2021-01-08 00:15:01 +00:00
return "[$id] $url $type: $message";
}
/**
* Get a normalised message for formatting with PSR-3 log event context.
*
* Must be used together with `getLogContext()` to be useful.
*
* @since 1.30
* @param Throwable $e
* @return string
*/
public static function getLogNormalMessage( Throwable $e ) {
if ( $e instanceof INormalizedException ) {
$message = $e->getNormalizedMessage();
} else {
$message = $e->getMessage();
}
if ( !$e instanceof ErrorException ) {
// ErrorException is something we use internally to represent
// PHP errors (runtime warnings that aren't thrown or caught),
// don't bother putting it in the logs. Let the log message
// lead with "PHP Warning: " instead (see ::handleError).
$message = get_class( $e ) . ": $message";
}
return "[{reqId}] {exception_url} $message";
}
/**
* @param Throwable $e
* @return string
*/
public static function getPublicLogMessage( Throwable $e ) {
Provide a unique request identifier When MediaWiki encounters an unhandled exception, the error message it produces includes a randomly-generated token, which allows the exception details to be looked up in the error logs. This is useful but narrow: would it not be useful to have the ability to retrieve all log records associated with a particular request, rather than just exception details? (Hint: yes.) So: introduce the notion of a request-global unique ID, retrievable via WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id (which provides the same facility) or some other software which sets a UNIQUE_ID envvar, the value of that envvar is used as the request ID. Otherwise, it is a randomly-generated 24-character string. The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId() is deprecated, accordingly. The request ID is also added as an annotation to all Monolog-processed log records, and is exposed client-side as 'wgRequestId'. This allows developers to associate a page view with log records even when the page view does not result in an unhandled exception. (For the WMF, I also intend to add it as an annotation to profiling data). The request ID is not a tracking token; it does not persist, and it is associated with a backend request, not with a particular user or a particular session. Like the data in the NewPP report, the request ID is designed to be cacheable, so that if, for example, a developer notices something weird in the HTML, s/he can associate the output with a backend request regardless of whether the response was served from the cache or directly from the backend. Some prior art: * https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html * http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html * https://github.com/dabapps/django-log-request-id * https://packagist.org/packages/php-middleware/request-id * https://github.com/rhyselsmore/flask-request-id Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
2016-03-25 01:43:23 +00:00
$reqId = WebRequest::getRequestId();
$type = get_class( $e );
Provide a unique request identifier When MediaWiki encounters an unhandled exception, the error message it produces includes a randomly-generated token, which allows the exception details to be looked up in the error logs. This is useful but narrow: would it not be useful to have the ability to retrieve all log records associated with a particular request, rather than just exception details? (Hint: yes.) So: introduce the notion of a request-global unique ID, retrievable via WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id (which provides the same facility) or some other software which sets a UNIQUE_ID envvar, the value of that envvar is used as the request ID. Otherwise, it is a randomly-generated 24-character string. The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId() is deprecated, accordingly. The request ID is also added as an annotation to all Monolog-processed log records, and is exposed client-side as 'wgRequestId'. This allows developers to associate a page view with log records even when the page view does not result in an unhandled exception. (For the WMF, I also intend to add it as an annotation to profiling data). The request ID is not a tracking token; it does not persist, and it is associated with a backend request, not with a particular user or a particular session. Like the data in the NewPP report, the request ID is designed to be cacheable, so that if, for example, a developer notices something weird in the HTML, s/he can associate the output with a backend request regardless of whether the response was served from the cache or directly from the backend. Some prior art: * https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html * http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html * https://github.com/dabapps/django-log-request-id * https://packagist.org/packages/php-middleware/request-id * https://github.com/rhyselsmore/flask-request-id Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
2016-03-25 01:43:23 +00:00
return '[' . $reqId . '] '
. gmdate( 'Y-m-d H:i:s' ) . ': '
. 'Fatal exception of type "' . $type . '"';
}
/**
* Get a PSR-3 log event context from a Throwable.
*
* Creates a structured array containing information about the provided
* throwable that can be used to augment a log message sent to a PSR-3
* logger.
*
* @since 1.26
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
* @return array
*/
public static function getLogContext( Throwable $e, $catcher = self::CAUGHT_BY_OTHER ) {
$context = [
'exception' => $e,
'exception_url' => self::getURL() ?: '[no req]',
// The reqId context key use the same familiar name and value as the top-level field
// provided by LogstashFormatter. However, formatters are configurable at run-time,
// and their top-level fields are logically separate from context keys and cannot be,
// substituted in a message, hence set explicitly here. For WMF users, these may feel,
// like the same thing due to Monolog V0 handling, which transmits "fields" and "context",
// in the same JSON object (after message formatting).
'reqId' => WebRequest::getRequestId(),
'caught_by' => $catcher
];
if ( $e instanceof INormalizedException ) {
$context += $e->getMessageContext();
}
return $context;
}
/**
* Get a structured representation of a Throwable.
*
* Returns an array of structured data (class, message, code, file,
* backtrace) derived from the given throwable. The backtrace information
* will be redacted as per getRedactedTraceAsArray().
*
* @since 1.26
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
* @return array
*/
public static function getStructuredExceptionData(
Throwable $e,
$catcher = self::CAUGHT_BY_OTHER
) {
global $wgLogExceptionBacktrace;
$data = [
Provide a unique request identifier When MediaWiki encounters an unhandled exception, the error message it produces includes a randomly-generated token, which allows the exception details to be looked up in the error logs. This is useful but narrow: would it not be useful to have the ability to retrieve all log records associated with a particular request, rather than just exception details? (Hint: yes.) So: introduce the notion of a request-global unique ID, retrievable via WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id (which provides the same facility) or some other software which sets a UNIQUE_ID envvar, the value of that envvar is used as the request ID. Otherwise, it is a randomly-generated 24-character string. The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId() is deprecated, accordingly. The request ID is also added as an annotation to all Monolog-processed log records, and is exposed client-side as 'wgRequestId'. This allows developers to associate a page view with log records even when the page view does not result in an unhandled exception. (For the WMF, I also intend to add it as an annotation to profiling data). The request ID is not a tracking token; it does not persist, and it is associated with a backend request, not with a particular user or a particular session. Like the data in the NewPP report, the request ID is designed to be cacheable, so that if, for example, a developer notices something weird in the HTML, s/he can associate the output with a backend request regardless of whether the response was served from the cache or directly from the backend. Some prior art: * https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html * http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html * https://github.com/dabapps/django-log-request-id * https://packagist.org/packages/php-middleware/request-id * https://github.com/rhyselsmore/flask-request-id Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
2016-03-25 01:43:23 +00:00
'id' => WebRequest::getRequestId(),
'type' => get_class( $e ),
'file' => $e->getFile(),
'line' => $e->getLine(),
'message' => $e->getMessage(),
'code' => $e->getCode(),
'url' => self::getURL() ?: null,
'caught_by' => $catcher
];
if ( $e instanceof ErrorException &&
( error_reporting() & $e->getSeverity() ) === 0
) {
// Flag surpressed errors
$data['suppressed'] = true;
}
if ( $wgLogExceptionBacktrace ) {
$data['backtrace'] = self::getRedactedTrace( $e );
}
$previous = $e->getPrevious();
if ( $previous !== null ) {
$data['previous'] = self::getStructuredExceptionData( $previous, $catcher );
}
return $data;
}
/**
* Serialize a Throwable object to JSON.
*
* The JSON object will have keys 'id', 'file', 'line', 'message', and
* 'url'. These keys map to string values, with the exception of 'line',
* which is a number, and 'url', which may be either a string URL or
* null if the throwable did not occur in the context of serving a web
* request.
*
* If $wgLogExceptionBacktrace is true, it will also have a 'backtrace'
* key, mapped to the array return value of Throwable::getTrace, but with
* each element in each frame's "args" array (if set) replaced with the
* argument's class name (if the argument is an object) or type name (if
* the argument is a PHP primitive).
*
* @par Sample JSON record ($wgLogExceptionBacktrace = false):
* @code
* {
* "id": "c41fb419",
* "type": "MWException",
* "file": "/var/www/mediawiki/includes/cache/MessageCache.php",
* "line": 704,
* "message": "Non-string key given",
* "url": "/wiki/Main_Page"
* }
* @endcode
*
* @par Sample JSON record ($wgLogExceptionBacktrace = true):
* @code
* {
* "id": "dc457938",
* "type": "MWException",
* "file": "/vagrant/mediawiki/includes/cache/MessageCache.php",
* "line": 704,
* "message": "Non-string key given",
* "url": "/wiki/Main_Page",
* "backtrace": [{
* "file": "/vagrant/mediawiki/extensions/VisualEditor/VisualEditor.hooks.php",
* "line": 80,
* "function": "get",
* "class": "MessageCache",
* "type": "->",
* "args": ["array"]
* }]
* }
* @endcode
*
* @since 1.23
* @param Throwable $e
* @param bool $pretty Add non-significant whitespace to improve readability (default: false).
* @param int $escaping Bitfield consisting of FormatJson::.*_OK class constants.
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
* @return string|false JSON string if successful; false upon failure
*/
public static function jsonSerializeException(
Throwable $e,
$pretty = false,
$escaping = 0,
$catcher = self::CAUGHT_BY_OTHER
) {
return FormatJson::encode(
self::getStructuredExceptionData( $e, $catcher ),
$pretty,
$escaping
);
}
/**
* Log a throwable to the exception log (if enabled).
*
* This method must not assume the throwable is an MWException,
* it is also used to handle PHP exceptions or exceptions from other libraries.
*
* @since 1.22
* @param Throwable $e
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
* @param array $extraData (since 1.34) Additional data to log
*/
public static function logException(
Throwable $e,
$catcher = self::CAUGHT_BY_OTHER,
$extraData = []
) {
if ( !( $e instanceof MWException ) || $e->isLoggable() ) {
$logger = LoggerFactory::getInstance( 'exception' );
$context = self::getLogContext( $e, $catcher );
if ( $extraData ) {
$context['extraData'] = $extraData;
}
$logger->error(
self::getLogNormalMessage( $e ),
$context
);
$json = self::jsonSerializeException( $e, false, FormatJson::ALL_OK, $catcher );
if ( $json !== false ) {
$logger = LoggerFactory::getInstance( 'exception-json' );
$logger->error( $json, [ 'private' => true ] );
}
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
Hooks::runner()->onLogException( $e, false );
}
}
/**
* Log an exception that wasn't thrown but made to wrap an error.
*
* @param ErrorException $e
* @param string $channel
* @param string $level
* @param string $catcher CAUGHT_BY_* class constant indicating what caught the error
*/
private static function logError(
ErrorException $e,
$channel,
$level,
$catcher
) {
// The set_error_handler callback is independent from error_reporting.
// Filter out unwanted errors manually (e.g. when
// Wikimedia\suppressWarnings is active).
$suppressed = ( error_reporting() & $e->getSeverity() ) === 0;
if ( !$suppressed ) {
$logger = LoggerFactory::getInstance( $channel );
$logger->log(
$level,
self::getLogNormalMessage( $e ),
self::getLogContext( $e, $catcher )
);
}
// Include all errors in the json log (surpressed errors will be flagged)
$json = self::jsonSerializeException( $e, false, FormatJson::ALL_OK, $catcher );
if ( $json !== false ) {
$logger = LoggerFactory::getInstance( "{$channel}-json" );
// Unlike the 'error' channel, the 'error-json' channel is unfiltered,
// and emits messages even if wikimedia/at-ease was used to suppress the
// error. To avoid clobbering Logstash dashboards with these, make sure
// those have their level casted to DEBUG so that they are excluded by
// level-based filteres automatically instead of requiring a dedicated filter
// for this channel. To be improved: T193472.
$unfilteredLevel = $suppressed ? LogLevel::DEBUG : $level;
$logger->log( $unfilteredLevel, $json, [ 'private' => true ] );
}
Hooks::run() call site migration Migrate all callers of Hooks::run() to use the new HookContainer/HookRunner system. General principles: * Use DI if it is already used. We're not changing the way state is managed in this patch. * HookContainer is always injected, not HookRunner. HookContainer is a service, it's a more generic interface, it is the only thing that provides isRegistered() which is needed in some cases, and a HookRunner can be efficiently constructed from it (confirmed by benchmark). Because HookContainer is needed for object construction, it is also needed by all factories. * "Ask your friendly local base class". Big hierarchies like SpecialPage and ApiBase have getHookContainer() and getHookRunner() methods in the base class, and classes that extend that base class are not expected to know or care where the base class gets its HookContainer from. * ProtectedHookAccessorTrait provides protected getHookContainer() and getHookRunner() methods, getting them from the global service container. The point of this is to ease migration to DI by ensuring that call sites ask their local friendly base class rather than getting a HookRunner from the service container directly. * Private $this->hookRunner. In some smaller classes where accessor methods did not seem warranted, there is a private HookRunner property which is accessed directly. Very rarely (two cases), there is a protected property, for consistency with code that conventionally assumes protected=private, but in cases where the class might actually be overridden, a protected accessor is preferred over a protected property. * The last resort: Hooks::runner(). Mostly for static, file-scope and global code. In a few cases it was used for objects with broken construction schemes, out of horror or laziness. Constructors with new required arguments: * AuthManager * BadFileLookup * BlockManager * ClassicInterwikiLookup * ContentHandlerFactory * ContentSecurityPolicy * DefaultOptionsManager * DerivedPageDataUpdater * FullSearchResultWidget * HtmlCacheUpdater * LanguageFactory * LanguageNameUtils * LinkRenderer * LinkRendererFactory * LocalisationCache * MagicWordFactory * MessageCache * NamespaceInfo * PageEditStash * PageHandlerFactory * PageUpdater * ParserFactory * PermissionManager * RevisionStore * RevisionStoreFactory * SearchEngineConfig * SearchEngineFactory * SearchFormWidget * SearchNearMatcher * SessionBackend * SpecialPageFactory * UserNameUtils * UserOptionsManager * WatchedItemQueryService * WatchedItemStore Constructors with new optional arguments: * DefaultPreferencesFactory * Language * LinkHolderArray * MovePage * Parser * ParserCache * PasswordReset * Router setHookContainer() now required after construction: * AuthenticationProvider * ResourceLoaderModule * SearchEngine Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
2020-03-19 02:42:09 +00:00
Hooks::runner()->onLogException( $e, $suppressed );
}
}