Last modified: 2014-02-05 21:33:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40095, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 38095 - Error handling information reduced: "Fatal exception of type MWException" is somewhat useless
Error handling information reduced: "Fatal exception of type MWException" is ...
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
: platformeng
Depends on:
Blocks: 24675 36739 37131 37364 37978 38035 38600 39336 41258
  Show dependency treegraph
 
Reported: 2012-07-01 01:16 UTC by Sam Reed (reedy)
Modified: 2014-02-05 21:33 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sam Reed (reedy) 2012-07-01 01:16:40 UTC
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"
Comment 1 Bawolff (Brian Wolff) 2012-07-03 00:57:47 UTC
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.
Comment 2 Bartosz Dziewoński 2012-10-24 18:48:21 UTC
Boldly bumping to major. This seriously hinders debugging of ContentHandler stuff right now.

Is this as simple as a one-line config change?
Comment 3 Roan Kattouw 2012-10-24 18:50:43 UTC
(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.
Comment 4 Sam Reed (reedy) 2012-10-24 18:52:38 UTC
(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.

Yes http://i50.tinypic.com/1zfk1va.png
Comment 5 Mormegil 2012-11-20 10:00:07 UTC
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…
Comment 6 Bawolff (Brian Wolff) 2012-11-20 16:05:25 UTC
(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)
Comment 7 Liangent 2012-11-20 16:10:23 UTC
(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.
Comment 8 Bawolff (Brian Wolff) 2012-11-20 16:15:22 UTC
(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)
Comment 9 Brad Jorsch 2012-11-20 16:18:41 UTC
(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.
Comment 10 Nemo 2012-11-20 16:22:20 UTC
(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
> 4)

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).
Comment 11 Max Semenik 2013-01-12 12:29:47 UTC
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.
Comment 12 Philosopher 2013-01-29 17:23:31 UTC
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!
Comment 13 Nemo 2013-01-29 17:42:40 UTC
(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.
Comment 14 Bawolff (Brian Wolff) 2013-01-29 18:07:06 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links