This changes the current:
> Internal error.
To be:
> [89466ede] 2015-09-23 16:40: Fatal exception of type Less_Exception
This matches how exceptions are reported on HTML pages by MediaWiki
(via MWException::getHTML in OutputPage).
The IDs are okay to be public and exposed on HTML pages even when
$wgShowExceptionDetails is disabled.
Follows-up d478ffde10. Ref T110659.
Change-Id: I501eaa629161184ba89d44e53cdac20b39cb0903
Make MediaWiki\Logger\LegacyLogger and
MediaWiki\Logger\Monolog\LineFormatter better at outputting stacktrace
information and provide support for 'exception' data in the logging
context that is a structured array in addition to the default Exception
object support. This works with MWExceptionHandler::handleFatalError
generated data that is provided by an HHVM interpreter and cannot be
delivered as an Exception class.
With this patch, a good value for LineFormatter's format would be:
"%datetime% %extra.host% %extra.wiki% %channel% %level_name%: %message%
%context% %exception%\n"
Bug: T89169
Bug: T107440
Change-Id: Ida01ed51c573e1654346e716723e543a1be63090
Split fatal error handling out of MWExceptionHandler::handleError() and
move to MWExceptionHandler::handleFatalError() which has been updated to
work as a dual purpose error handler and shutdown function. Under HHVM
it will be called as an error handler and receive a stacktrace via an
undocumented extension of the error handler callback data. Under PHP5 it
will be called as a shutdown handler and attempt to gather data via
error_get_last().
Also update the error handler installed by Hooks::run() to delegate to
MWExceptionHandler::handleError() for most errors. This will allow us to
properly handle errors raised from within hooks.
Bug: T89169
Change-Id: I0f1c66f203b91fff9069520169ecc4a3b55c43d0
* $wgLogExceptionBacktrace from MWExceptionHandler
unused since 77a397125f
* $wgPasswordPolicy from WebInstallerName
unused since 6a69a4eb73
Change-Id: Ibaac1bad05f4326a2602958a93d4d46135bdca63
Replace wfDebugLog() calls in MWExceptionHandler with direct use of
LoggerFactory and LoggerInterface. Logged exceptions are added to the
log message context.
LegacyLogger is also updated to append stack traces to any log event
when $wgLogExceptionBacktrace is true and the PSR-3 recommendation of
passing the exception as an 'exception' context item.
Handling of context data in LegacyLogger is expanded to support arrays,
exceptions and common object types.
Bug: T88649
Change-Id: I71499d895582bdea033a2516c902e23e38084080
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
This makes sure static analyzers don't warn for supposedly unsafe
code accessing variables as strings when they could be boolean after
having only checked against false.
https://github.com/scrutinizer-ci/php-analyzer/issues/605
Change-Id: Idb676de7587f1eccb46c12de0131bea4489a0785
* Do not bother with profiling data, which is just another
thing that can go wrong.
* Catch DB rollback errors to avoid getting stuck in
report() loops during network partitions.
Change-Id: I92293b2261c48cf49625ea14a51987e5619ab8d4
'error' is currently disabled in Wikimedia production, but we still need
to log stack traces for fatals.
Bug: T89169
Change-Id: Id0255651f228037152b87022f5eb696c1050b9ec
MWExceptionHandler::handleFatalError() is installed as a shutdown
function to inspect `error_get_last()` output and log the error via
MWExceptionHandler::logError(). The error is examined to determine if it
is a missing class error so that a descriptive log message can be
provided instructing the server administrator on 3rd party library
installation methods.
Bug: T74777
Change-Id: I04748626487022c51050ffa7846236947a082d68
Follows-up 399ba2fecf which didn't include any translation of the error
type in the logged message (e.g. "PHP Notice" or "PHP Warning").
Before
Error from line 2130 of mediawiki/includes/OutputPage.php: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: strpos() expects at le..
After
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Notice: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Warning: strpos() expects at le..
Based on the log formatter in php
https://github.com/php/php-src/blob/0f5858e3a328/main/main.c#L1086-L1119
Change-Id: I52f98e52caa64955050ed73e1acbc78b1116a9fd
* Remove use of 'error' where it's redundant.
* Remove call to logException from responsibility of MWException.
Call from exception handler instead.
Change-Id: I8764cf5df87b226813c9b9cf99f9b4f3fa4b7c92
Previously, non-MediaWiki exceptions were logged only for api requests,
job runner, resource loader, etc. but not for general requests
such as page views.
Bug: 61914
Change-Id: Id4de5cac0b9996a98cdaf5e73655d49fa55ea8c3
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
