Remove the exit(1), which does not seem to be needed by any callers.
Doing so means that post-send updates can still happen, such as the
pushing of lazy jobs.
Better avoid showing exceptions in doPostOutputShutdown(), given
that an error may have already been shown. By the post-send part,
it's to late to show errors anyway.
Bug: T100085
Change-Id: Ib1c75323f222a0e02603d6415626a4b233e8e1c7
MWExceptionHandler::rollbackMasterChangesAndLog() only logged exceptions
if there were already master changes. This is extremely problematic when
debugging, especially in situations like DeferredUpdates where they were
silently being swallowed.
This makes it log exceptions in all paths, erring on the side of logging
the same exception twice (theoretically it's possible I suppose) instead
of not at all.
Also make the method able to handle DBError exceptions, which most of
the callers seemed to be assuming. ApiMain was handling this explicitly.
Bug: T168347
Change-Id: I8739051f824a455ba669344184c3b11ac95cb561
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
This distinguishes random errors caught and explicitly logged by various
callers from those that were only caught by the registered exception handler.
The later are likely to have more visibily impact on the user.
Change-Id: Icb4c4e9376270c5475c95cf40708a7ca3e4e0a49
When we create an exception-like set of data for logging in
MWExceptionHandler::handleFatalError, add it to the logging context as
a 'fatal_exception' member. The 'exception' value in a log context
should only be populated with a real Exception object.
Bug: T150106
Change-Id: I253943849f19ed5480dbda7bfbc0bf607f69c47d
* Make isTransactableQuery() exclude CREATE/ALTER.
Starting transactions for schema changes like this can cause
errors as it is not supported for MySQL and some Postgres
operations. Note that temporary tables are session-level,
so they are not effected by this change.
* Clean up the transaction logic in determineCoreSchema()
so a transaction is not left dangling.
* Fix broken getSchemaPath() call in PostgresInstaller.
* Avoid warnings in DatabasePostgres::closeConnection() if
mConn is already unset.
* Commit master changes in doMaintenance.php before running
deferred updates, just as MediaWiki.php does.
* Change E_WARNING to E_USER_WARNING to avoid notices in the
default /rdbms error handlers.
* Also avoid trying to rollback in MWExceptionHandler if the
LBFactory service is disabled, which just results in an error.
Bug: T147599
Change-Id: I64ccab7f9b74f60309ba0c9a8ce68337c42ffb0f
* Actually use MWExceptionRenderer::AS_RAW. Use this after
an error is thrown while trying to pretty render the original
error. This is how this case was originally handled before.
* Do not show the google form or file cache in CLI mode.
Change-Id: I130499753efbf8b4d6d254ea36bacb2473952c1b
Follow up to 00bee0297. Many MWException subclasses override
MWException::report to do things like special logging and setting the
HTTP response status code. We need to keep calling those methods until
MWExceptionRenderer knows how to handle all of them.
Bug: T147098
Change-Id: I2c90e2d9e9b019357458c7e14a3d602b591c6f5b
* This handles the work of showing exceptions so that
MWException does not have too.
* Simplify the DBError classes to regular Exception
classes. Lots of pointless prettification has been
removed, but DBConnectionError still gets the usual
special treatment of a fallback page and Google form.
* Remove hacky file cache fallback code that probably
did not work.
* Make MWExceptionHandler::report() wrap
MWExceptionExposer::output().
* Make MWException::runHooks() wrap
MWExceptionExposer::runHooks().
Change-Id: I5dfdc84e94ddac65417226cf7c84513ebb9f9faa
* Also make ErrorPageError exceptions display themselves
in PRESEND mode. Before they were always suppressed.
* Make DataUpdate::runUpdates() simply wrap
DeferredUpdates::execute().
* Remove unused installDBListener() method, which was
basically moved to Maintenance.
* Enable DBO_TRX for DeferredUpdates::execute() in CLI mode
* Also perform sub-DeferrableUpdate jobs right after their
parent for better transaction locality.
* Made rollbackMasterChangesAndLog() clear all master
transactions/rounds, even if there are no changes yet.
This keeps the state cleaner for continuing.
* For sanity, avoid calling acquirePageLock() in link updates
unless the transaction ticket is set. These locks are
already redundant and weaker in range than the locks the
Job classes that run them get. This helps guard against
DBTransactionError.
* Renamed $type to $stage to be more clear about the order.
Change-Id: I1e90b56cc80041d70fb9158ac4f027285ad0f2c9
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
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
