Last modified: 2014-11-18 07:04:21 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 T56193, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54193 - Warning: Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284
Warning: Recursion detected in RequestContext::getLanguage in /includes/cont...
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.23.0
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 69023
  Show dependency treegraph
 
Reported: 2013-09-16 23:07 UTC by Sam Reed (reedy)
Modified: 2014-11-18 07:04 UTC (History)
11 users (show)

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


Attachments
stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log (6.71 KB, application/octet-stream)
2013-11-21 11:15 UTC, Ori Livneh
Details

Description Sam Reed (reedy) 2013-09-16 23:07:15 UTC
I thought there was a bug for this, but I can't find it...

Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.22wmf16/includes/context/RequestContext.php on line 281


The amount of the warnings seems to have increased a lot more in wmf16/wmf17
Comment 1 Niklas Laxström 2013-09-17 06:02:42 UTC
I can't do anything about this without a backtrace. Not sure how to mark that.
Comment 2 Siebrand Mazeland 2013-11-12 08:50:01 UTC
Sam, are these still being observed, or have they gone away?
Comment 3 Sam Reed (reedy) 2013-11-12 17:27:38 UTC
Yup, there are these warnings almost always shown in the last 1000 lines of the apache syslogs
Comment 4 Sam Reed (reedy) 2013-11-12 22:34:21 UTC
Every 2.0s: tail -n 1000 /home/wikipedia/syslog/apache.log | grep -v 'Search backend error' | grep -v -i 'swift' | grep 'PHP\|Segmentation ...  Tue Nov 12 22:33:46 2013

    240 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf3/includes/context/RequestContext.php on line 284
     72 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf2/includes/context/RequestContext.php on line 284
Comment 5 Ori Livneh 2013-11-21 00:33:35 UTC
>200 of these every hour in /a/mw-log/apache2.log
Comment 6 Siebrand Mazeland 2013-11-21 03:32:47 UTC
Would it be possible to provide more information about which wiki(s) display this behavior, or possibly even page(s)?

Being able t reproduce this would probably go a long way towards resolving it.
Comment 7 Siebrand Mazeland 2013-11-21 03:35:00 UTC
Side note: the logs this information is extracted from, could we make those more widely available so they could get more eyeballs? From my experience doing this at translatewiki.net it often helps in identifying issues a lot earlier.
Comment 8 Gerrit Notification Bot 2013-11-21 08:21:31 UTC
Change 96709 had a related patch set uploaded by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709
Comment 9 Gerrit Notification Bot 2013-11-21 08:37:24 UTC
Change 96709 merged by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709
Comment 10 Ori Livneh 2013-11-21 11:15:56 UTC
Created attachment 13858 [details]
stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log
Comment 11 Ori Livneh 2013-11-21 11:19:06 UTC
(In reply to comment #6)
> Would it be possible to provide more information about which wiki(s) display
> this behavior, or possibly even page(s)? Being able t reproduce this would
> probably go a long way towards resolving it.

I added a trace; additional ones are available in fluorine:/a/mw-log/recursion-guard-stack-trace.log. If you want me to grab additional ones, let me know.

(In reply to comment #7)
> Side note: the logs this information is extracted from, could we make those
> more widely available so they could get more eyeballs? From my experience
> doing this at translatewiki.net it often helps in identifying issues a lot
> earlier.

Yeah, fair point. We (platform & ops) are working on setting up a better platform for log analysis, probably using logstash. The current situation sucks.
Comment 12 Niklas Laxström 2013-11-21 12:47:43 UTC
What a scary backtrace. It seems to relate on automatic creation of local accounts interacting with abuse filter. No wonder it seems to only happen in production.

I have no idea how to fix this. Perhaps automatic local account creation should happen somewhere else?
Comment 13 Siebrand Mazeland 2013-11-21 13:37:51 UTC
Given the backtrace, this does not seem to be an i18n issue, except for that the class (Stub)Language is involved at one level. Reclassifying and updating CCs accordingly. Niklas and I will stay on CC.
Comment 14 Nemo 2013-11-21 14:11:39 UTC
(In reply to comment #12)
> What a scary backtrace. It seems to relate on automatic creation of local
> accounts interacting with abuse filter. No wonder it seems to only happen in
> production.
> 
> I have no idea how to fix this. Perhaps automatic local account creation
> should
> happen somewhere else?

cc Anomie
Comment 15 Brad Jorsch 2013-11-21 16:44:30 UTC
So the problem generally appears to be that Language::getLanguage() unstubs the User object by trying to fetch the 'language' pref, and the various hooks called during that process may themselves wind up doing something that tries to call Language::getLanguage(). There are also some instances where something hooking 'UserGetLanguageObject' tries to call getLanguage().

Code paths I see in a quick look through the log include:
* getLanguage() → Log in from cookies → Trying to get the localized alias for NS_USER on wikis with variants → getLanguage()
** This seems to be a large number of the instances: srwiki, uzwiktionary, kuwiktionary, etc.
* getLanguage() → Autocreate account → AbuseFilter's checkNewAccount hook → dividebyzero → Trying to get localized error message → getLanguage()
** enwiki and eswiki have this
* getLanguage() → ULS's getLanguage hook → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → TitleBlacklist hit → Trying to get localized error message → getLanguage()
* getLanguage() → Autocreate account → NewUserMessage::createNewUserMessage → various different code paths involving the parser and/or MessageCache → getLanguage()

I think that the fallback behavior added in Gerrit change #48080 is probably the best thing to do in general.

BTW, the previous bug on this topic was probably bug 44754.
Comment 16 Yuri Astrakhan 2013-12-18 21:11:45 UTC
Hiding the warning in fatal monitor with Gerrit change #102557 - the stacktrace logging is still on
Comment 17 Tim Starling 2013-12-19 22:33:33 UTC
Looks like bug 41201 again ("UserLoadFromSession considered evil"). I probably should have pushed that one a bit harder during the CA2 sprint. It should be a pretty simple change for Brad or Chris.
Comment 18 Nemo 2014-08-01 19:53:39 UTC
(In reply to Tim Starling from comment #17)
> Looks like bug 41201 again ("UserLoadFromSession considered evil"). I
> probably should have pushed that one a bit harder during the CA2 sprint. It
> should be a pretty simple change for Brad or Chris.

Is it?
Comment 19 Gerrit Notification Bot 2014-11-18 01:53:50 UTC
Change 174051 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051
Comment 20 Gerrit Notification Bot 2014-11-18 02:06:29 UTC
Change 174051 merged by jenkins-bot:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051
Comment 21 Gerrit Notification Bot 2014-11-18 02:25:43 UTC
Change 174057 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174057

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


Navigation
Links