Last modified: 2014-11-18 07:04:21 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
I can't do anything about this without a backtrace. Not sure how to mark that.
Sam, are these still being observed, or have they gone away?
Yup, there are these warnings almost always shown in the last 1000 lines of the apache syslogs
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
>200 of these every hour in /a/mw-log/apache2.log
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.
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.
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
Change 96709 merged by Ori.livneh: Enable recursion-guard log bucket to investigate bug 54193 https://gerrit.wikimedia.org/r/96709
Created attachment 13858 [details] stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log
(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.
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?
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.
(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
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.
Hiding the warning in fatal monitor with Gerrit change #102557 - the stacktrace logging is still on
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.
(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?
Change 174051 had a related patch set uploaded by Ori.livneh: Avoid calling Title::makeTitleSafe in User::idFromName https://gerrit.wikimedia.org/r/174051
Change 174051 merged by jenkins-bot: Avoid calling Title::makeTitleSafe in User::idFromName https://gerrit.wikimedia.org/r/174051
Change 174057 had a related patch set uploaded by Ori.livneh: Avoid calling Title::makeTitleSafe in User::idFromName https://gerrit.wikimedia.org/r/174057