Last modified: 2012-10-21 17:03:25 UTC
Page error at Commons: http://commons.wikimedia.org/wiki/File:Juan_Andreu_con_la_selecci%C3%B3n.jpg "[b6200044] 2012-06-26 23:56:49: Fatal exception of type MWException" That is the only case up to now. See http://commons.wikimedia.org/wiki/Commons:Village_pump#Internal_error (Perm: http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=73338539#Internal_error ) In case that matters: "Served by srv285 in 0.142 secs" (from source). Happens regardless of logged in / not logged in and regardless of http or https (tested logged in only via https).
We also had a report about this: <https://pt.wikipedia.org/w/index.php?search=media%3Atest.jpg&title=Especial%3APesquisar>
/me wonders what happened to the pretty stack traces?
http://commons.wikimedia.org/wiki/File:Ali_Al-Nono.jpg
(In reply to comment #2) > /me wonders what happened to the pretty stack traces? Back in the day, we didn't have server-side logging of exceptions in a sane way, so we had exceptions enabled on the live site. Nowadays with wmerrors, that's not really necessary so Tim disabled them. I've been kinda annoyed about how we leak private data in exceptions (bug 30714), and we realized that people's passwords might be intercepted in such a scenario (and a non-behaving cache might cache it!) However, the errors given right now aren't terribly useful either. What we should do is output some unique identifier to the user that can be used to pinpoint a specific log entry (rather than using timestamps and guessing).
The password thing is scary, but not having stack traces significantly hinders debugging things for those of us without access to the logs. Even if there was a unique id with the error - finding someone with appropriate access and getting what the actual error is from them is a lot more work then the previous situation.
These files work fine now. Reopen if it's still an issue
(In reply to comment #6) > These files work fine now. Reopen if it's still an issue Comment 2 doesn't work for me.
I think you mean comment 1 :)
(In reply to comment #7) > (In reply to comment #6) > > These files work fine now. Reopen if it's still an issue > > Comment 2 doesn't work for me. It's a completely different bug to the original reported bug. That, and it has an earlier bug itself logged at bug 37131
