Logging this against WMF, as I'm not sure if it's a config change, or more likely something in MW
Per Bawolff:
(In reply to comment #2)
/me wonders what happened to the pretty stack traces?
We're getting differences in error handling for some (unknown) reason. It needs dealing with an correcting/reverting
Logged 3 bugs as blocked by this issue due to the naff error information - "Fatal exception of type MWException"
Version: unspecified
Severity: major
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add i18n for the infamous "Fatal exception of type MWException" errorbox | mediawiki/core | master | +16 -6 |
HTML comment seems to indicate it was a config change. It says:
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
Boldly bumping to major. This seriously hinders debugging of ContentHandler stuff right now.
Is this as simple as a one-line config change?
(In reply to comment #0)
Logged 3 bugs as blocked by this issue due to the naff error information -
"Fatal exception of type MWException"
Do the error messages contain an ID string that looks like [2f5ca212] ? If so, you can ask a sysadmin to look up the exception message and backtrace in the logs.
(In reply to comment #3)
(In reply to comment #0)
Logged 3 bugs as blocked by this issue due to the naff error information -
"Fatal exception of type MWException"Do the error messages contain an ID string that looks like [2f5ca212] ? If so,
you can ask a sysadmin to look up the exception message and backtrace in the
logs.
This change was committed to Gerrit in Ieace3cd6d57b56559555ae0f1e6ec130e5d25c85 (“Updated config files per current usage”), changing
'default' => true, // fixme: log things instead
to
'default' => false,
Was this really neccessary? Are the exception details somehow sensitive (showing private information or something)? Or is it just about user-friendliness (well, a fatal exception is hardly user-friendly)? Couldn’t we just hide the exception details under a “click for technical details”, or even into an HTML comment?
You know, on a public _wiki_ running on open-source software, I might want to diagnose the problem a bit myself, rather than just posting a hexnumber to Bugzilla and waiting for someone with shell access to look it up in the server logs…
(In reply to comment #5)
This change was committed to Gerrit in
Ieace3cd6d57b56559555ae0f1e6ec130e5d25c85 (“Updated config files per current
usage”), changing
'default' => true, // fixme: log things instead
to
'default' => false,Was this really neccessary? Are the exception details somehow sensitive
(showing private information or something)? Or is it just about
user-friendliness (well, a fatal exception is hardly user-friendly)? Couldn’t
we just hide the exception details under a “click for technical details”, or
even into an HTML comment?You know, on a public _wiki_ running on open-source software, I might want to
diagnose the problem a bit myself, rather than just posting a hexnumber to
Bugzilla and waiting for someone with shell access to look it up in the server
logs…
+5 billion. Getting the info from a sysadmin in some cases is more work then fixing the issue. Its also important to have this info to triage bugs.
Are the exception details somehow sensitive
(showing private information or something)?
There was. My understanding is that issue has been fixed. (Exceptions in password related code was showing passwords)
(In reply to comment #6)
+5 billion. Getting the info from a sysadmin in some cases is more work then
fixing the issue. Its also important to have this info to triage bugs.
The only useful case may be when a developer without op access can see the backtrace the bug may be fixed immediately.
(In reply to comment #7)
(In reply to comment #6)
+5 billion. Getting the info from a sysadmin in some cases is more work then
fixing the issue. Its also important to have this info to triage bugs.The only useful case may be when a developer without op access can see the
backtrace the bug may be fixed immediately.
Well that's a main one for sure (And the one that most directly applies to me). However there's other. User's can figure out if their issue is already filed or not based on the error message received. Sometimes the report with just the hex number lingers too long to make it easy to retrieve (Example: bug 39336 comment 4)
(In reply to comment #5)
Was this really neccessary? Are the exception details somehow sensitive
(showing private information or something)?
They can, yes. See for example bug 7096. The documentation for
$wgShowExceptionDetails ([[mw:Manual:$wgShowExceptionDetails]]) also mentions
this.
(In reply to comment #8)
(In reply to comment #7)
(In reply to comment #6)
+5 billion. Getting the info from a sysadmin in some cases is more work then
fixing the issue. Its also important to have this info to triage bugs.The only useful case may be when a developer without op access can see the
backtrace the bug may be fixed immediately.Well that's a main one for sure (And the one that most directly applies to me).
However there's other. User's can figure out if their issue is already filed or
not based on the error message received. Sometimes the report with just the hex
number lingers too long to make it easy to retrieve (Example: bug 39336 comment
Does this really still need to be proved? It's quite obvious that the error messages without error messages and just with codes are useless; it's only slightly better than not showing any error and just relying on the sysadmins to carefully skim the logs, or on the users to provide precise timestamps (which is by the way what most websites do, and they're all broken or – I guess – they have much more people reading the logs).
With all due respect, I've just seen MySQL credentials in exception backtrace. While this problem can be alleviated by setting $wgShowDBErrorBacktrace to false, it will not help for non-DBError exceptions that might still contain DB initialization in their backtraces.
With regards to Nemo's point, the current message is completely useless. If there's something sensitive in it, it makes sense not to display what caused it. But at least include a "you can report this error at xxx" notice!
(In reply to comment #12)
With regards to Nemo's point, the current message is completely useless. If
there's something sensitive in it, it makes sense not to display what caused
it. But at least include a "you can report this error at xxx" notice!
Hmm. This could be done, perhaps. You could file a bug against MediaWiki extensions>WikimediaMessages, maybe an override for the default message can be added, with a link to [[mw:How to report a bug]].
A few days ago I added pointers for people searching "Fatal exception of type MWException" on Meta and mw.o.
As a compromise could we include:
*The exception description (aka "foo" part of throw new MWException( 'foo' ) )
*A backtrace without the arguments included (just function names).
I can't imagine there would be sensitive information in that.
(In reply to comment #12)
With regards to Nemo's point, the current message is completely useless. If
there's something sensitive in it, it makes sense not to display what caused
it. But at least include a "you can report this error at xxx" notice!
[offtopic] I also miss the "Please enable $wgShowExceptionDetails" part being actual text instead of an html comment. There's a lot more errors from third parties not sure what to do about the error then there used to be. It'd be nice if (not on wikimedia) that was back to not being a comment.
Some related links.
Change 190372 had a related patch set uploaded (by Nemo bis):
Add i18n for the infamous "Fatal exception of type MWException" errorbox
Change 190379 had a related patch set uploaded (by Nemo bis):
Add link to report form in "Fatal exception of type X" errorbox
Change 190372 merged by jenkins-bot:
Add i18n for the infamous "Fatal exception of type MWException" errorbox
Change 190379 abandoned by Hashar:
Add link to report form in "Fatal exception of type X" errorbox
Reason:
Per my earlier comment, exposing Phabricator on each outage is going to cause mass filling of duplicate tasks.
Change 190379 restored by Nemo bis:
Add link to report form in "Fatal exception of type X" errorbox