Last modified: 2014-05-08 08:59:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 37209 - LinkCache doesn't currently know about this title
LinkCache doesn't currently know about this title
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: High major with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression, platformeng
: 37218 41187 41360 (view as bug list)
Depends on: 46397
Blocks: 39480 43899
  Show dependency treegraph
Reported: 2012-05-30 06:50 UTC by Niklas Laxström
Modified: 2014-05-08 08:59 UTC (History)
20 users (show)

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


Description Niklas Laxström 2012-05-30 06:50:03 UTC
2012-05-30 06:39:20 mediawiki-bw_: [3b3fa018] /w/i.php?title=User_talk%3AVugar_1981&oldid=2860745   Exception from line 2831 of /www/w/includes/Title.php: LinkCache doesn't currently know about this title: User_talk:Vugar_1981
#0 /www/w/extensions/LiquidThreads/classes/Dispatch.php(143): Title->isRedirect()
#1 /www/w/extensions/LiquidThreads/classes/Dispatch.php(214): LqtDispatch::isLqtPage(Object(Title))
#2 [internal function]: LqtDispatch::tryPage(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest), Object(MediaWiki))
#3 /www/w/includes/Hooks.php(216): call_user_func_array('LqtDispatch::tr...', Array)
#4 /www/w/includes/GlobalFunctions.php(3938): Hooks::run('MediaWikiPerfor...', Array)
#5 /www/w/includes/Wiki.php(473): wfRunHooks('MediaWikiPerfor...', Array)
#6 /www/w/includes/Wiki.php(277): MediaWiki->performAction(Object(Article))
#7 /www/w/includes/Wiki.php(592): MediaWiki->performRequest()
#8 /www/w/includes/Wiki.php(502): MediaWiki->main()
#9 /www/w/index.php(58): MediaWiki->run()
#10 {main}
Comment 1 Daniel Kinzler 2012-05-30 10:36:14 UTC
This error is triggered by a newly inserted check that asserts that the link cache actually knows about the title in question before using the link cache to determine whether a given title is a redirect.

In the past, the case that the LinkCache didn't know about the item went unnoticed, and isRedirect would just return false even though the page in question might have been a redirect.

The way Title::isRedirect() is implemented seems quite brittle to me: it relies on the LinkCache without any fallback, and there's no intrinsic mechanism to make sure the LinkCache was actually initialize for this title.

So... I believe this problem has existed for a long time, but only now has been made obvious by the explicit check.
Comment 2 Niklas Laxström 2012-05-30 14:05:29 UTC
Yes it is very explicit. We're hitting this every few minutes on and getting spammed on #mediawiki-i18n. It's mostly crawlers but I'm sure we are serving exceptions to normal users too.
Comment 3 Daniel Kinzler 2012-05-30 14:07:54 UTC
Well, what you were serving before was simply wrong (at least in some cases), because redirects were not handled as such. 

Anyway, all I'm saying is: it's a bug, it should be fixed, but not by ignoring the actual problem,. but by finding and fixing the cause.
Comment 4 Niklas Laxström 2012-05-30 14:13:19 UTC
I think we have enough information to find a/the cause. In the mean time I had to disable real time error reporting.
Comment 5 Brion Vibber 2012-06-03 10:58:21 UTC
We've got somebody getting this error during parser tests as well, during:
'Edit comment with link'

I'm can reproduce it by setting $wgLanguageCode = "de" and running parserTests.php:

Running test Edit comment with link... LinkCache doesn't currently know about this title: Main_Page
#0 /Library/WebServer/Documents/core/includes/Linker.php(139): Title->isRedirect()
#1 /Library/WebServer/Documents/core/includes/Linker.php(324): Linker::getLinkColour(Object(Title), 0)
#2 /Library/WebServer/Documents/core/includes/Linker.php(240): Linker::linkAttribs(Object(Title), Array, Array)
#3 /Library/WebServer/Documents/core/includes/Linker.php(1341): Linker::link(Object(Title), 'Main Page')
#4 [internal function]: Linker::formatLinksInCommentCallback(Array)
#5 /Library/WebServer/Documents/core/includes/Linker.php(1275): preg_replace_callback('/\[\[:?(.*?)(\|...', Array, 'I like the [[Ma...')
#6 /Library/WebServer/Documents/core/includes/Linker.php(1166): Linker::formatLinksInComment('I like the [[Ma...', Object(Title), false)
#7 /Library/WebServer/Documents/core/tests/parser/ Linker::formatComment('I like the [[Ma...', Object(Title), false)
#8 /Library/WebServer/Documents/core/tests/parser/ ParserTest->runTest('Edit comment wi...', 'I like the [[Ma...', 'I like the <a h...', 'comment', '')
#9 /Library/WebServer/Documents/core/tests/parser/ ParserTest->runTests(Object(TestFileIterator))
#10 /Library/WebServer/Documents/core/tests/parserTests.php(90): ParserTest->runTestsFromFiles(Array)
#11 {main}
Comment 6 Brion Vibber 2012-06-03 11:02:57 UTC
I'm provisionally reverting this in

Needs a little more baking before it's done. :)
Comment 7 Brion Vibber 2012-06-03 11:05:44 UTC
Revert is merged and should provisionally 'fix' the error cases, but a proper fix for the original issue is still outstanding.
Comment 8 Brion Vibber 2012-06-03 14:25:10 UTC
Looks like Title::isRedirect()'s lazy-initialization path assumes that Title::getArticleId()'s lazy-initialization path gets executed, running through the link cache.

Sometimes this isn't the case, but I'm not 100% sure why or how.

Adjacent two methods are making the same assumption, Daniel has found! Lovely. :)

Probably they should go ahead and use the link cache, but if the link cache entry isn't there, we can't necessarily assume that the property is missing. Should fall back to a direct load (or a more general load info).
Comment 9 Alexandre Emsenhuber [IAlex] 2012-06-03 14:30:23 UTC
I fixed some of them in Gerrit change #9853.
Comment 10 db [inactive,noenotif] 2012-06-08 00:04:44 UTC
*** Bug 37218 has been marked as a duplicate of this bug. ***
Comment 11 Krinkle 2012-10-04 20:55:49 UTC
Adding bugs reported as "1.20", "regression" and "critical" to 1.20 release milestone.
Comment 12 Siebrand Mazeland 2012-10-11 14:01:16 UTC
Aude submitted Gerrit change #27528 to address this issue after the ContentHandler branch merge.
Comment 13 Aude 2012-10-11 22:26:57 UTC
My patch doesn't fix the bug.  Instead, it removes the fatal exception.  A more proper solution is needed.  

This could be to check page_is_redirect in the database in cases where the title is not in the link cache.

The use case where the exception happened for me is with the recent changes and watchlist pages, using the enhanced changes.  There is a check in Linker::getLinkColour() if a title is a redirect, and sometimes this is called in a way that the link is not in the cache.
Comment 14 Sam Reed (reedy) 2012-10-18 22:11:38 UTC
*** Bug 41187 has been marked as a duplicate of this bug. ***
Comment 15 Tyler Romeo 2012-10-18 22:20:53 UTC
Maybe I'm missing something, but can't this be solved by just adding $linkCache->addLinkObj( $this ) before every call of $linkCache->getGoodLinkFieldObj()? Because then the title would be added to the cache. Or perhaps I'm misunderstanding the point of LinkCache.
Comment 16 Niklas Laxström 2012-10-22 13:25:18 UTC
Lately I'm getting lot of this error (every 10 minutes when my jobqueue is supposed to run). Title seems to always be a user page.

[22-Oct-2012 13:20:01] LinkCache doesn't currently know about this title: User:Duesentrieb
#0 /www/ Title->getLatestRevID()
#1 /www/ SMWParseData::storeData(Object(ParserOutput), Object(Title), true)
#2 [internal function]: SMWParseData::onLinksUpdateConstructed(Object(LinksUpdate))
#3 /www/ call_user_func_array('SMWParseData::o...', Array)
#4 /www/ Hooks::run('LinksUpdateCons...', Array)
#5 /www/ wfRunHooks('LinksUpdateCons...', Array)
#6 /www/ LinksUpdate->__construct(Object(Title), Object(ParserOutput), false)
#7 /www/ ParserOutput->getSecondaryDataUpdates(Object(Title), false)
#8 /www/ AbstractContent->getSecondaryDataUpdates(Object(Title), NULL, false, Object(ParserOutput))
#9 /www/ RefreshLinksJob::runForTitleInternal(Object(Title), Object(Revision), 'RefreshLinksJob...')
#10 /www/ RefreshLinksJob2->run()
#11 /www/ RunJobs->execute()
#12 /www/ require_once('/www/translatew...')
#13 {main}

Backtrace is always the same.
Comment 17 Sam Reed (reedy) 2012-10-24 18:42:26 UTC
*** Bug 41258 has been marked as a duplicate of this bug. ***
Comment 18 Bartosz Dziewoński 2012-10-24 19:51:05 UTC
Bumping priority. This apparently causes editors to be unable to view their watchlists on pl.wikipedia right now. (Two sysops confirmed it.)

Please, somebody fix it, it was reported in May :(
Comment 19 Bartosz Dziewoński 2012-10-24 21:29:13 UTC
Ic2d3f0b8 was merged and apparently stuff stopped blowing up. Not marking as fixed, as whatever caused the issue is still there.

Comment 20 Markus Krötzsch 2012-11-09 18:40:39 UTC
Bug 35962 has most likely been caused by the implicit failure of the LinkCache (we have worked around it there).

The explicit failure also broke other functions in Semantic MediaWiki. It is better since the exception is gone (the exception killed runJobs.php, which was a bit painful), but Semantic MediaWiki will remain affected (storing wrong page metadata when refreshjobs are run) until this problem is solved.
Comment 21 Nemo 2012-11-09 22:10:51 UTC
Changing target milestone to 1.20.x. It's definitely worth an update to 1.20.0.
Comment 22 Vitaliy Filippov 2012-11-20 18:20:19 UTC
Discovered this bug when testing my rebased patch for bug 22881.

Of course it breaks sometimes! The code in Title.php should not rely on entries in the LinkCache - at least, it can be sometimes cleared!
Comment 23 Niklas Laxström 2012-12-07 21:50:42 UTC
This also triggers errors on some of the core unit tests on my environment:

1) WikitextContentTest::testGetSecondaryDataUpdates with data set #0 ('WikitextContentTest_testGetSecondaryDataUpdates_1', 'wikitext', 'hello \'\'world\'\'
', array(array(true, array())))
MWException: LinkCache doesn't currently know about this title: WikitextContentTest_testGetSecondaryDataUpdates_1


2) WikitextContentTest::testGetSecondaryDataUpdates with data set #1 ('WikitextContentTest_testGetSecondaryDataUpdates_2', 'wikitext', 'hello [[world test 21344]]
', array(array(true, array(array(0)))))
MWException: LinkCache doesn't currently know about this title: WikitextContentTest_testGetSecondaryDataUpdates_2

Comment 24 Andre Klapper 2012-12-17 01:38:15 UTC
(In reply to comment #15)
> Maybe I'm missing something, but can't this be solved by just adding
> $linkCache->addLinkObj( $this ) before every call of
> $linkCache->getGoodLinkFieldObj()? Because then the title would be added to
> the cache. Or perhaps I'm misunderstanding the point of LinkCache.

Could somebody comment on this, please?
Comment 25 Andre Klapper 2013-01-11 14:27:47 UTC
Bumping to highest priority after IRC discussion with Niklas and Sumana.

<Nikerabbit> that exception is popping up in various places regularly, and is very annoying... the lqt double posting (bug 43693) was just latest one
Comment 26 Vitaliy Filippov 2013-01-11 14:40:13 UTC
I have a fix for it here :-)
Comment 27 Siebrand Mazeland 2013-01-11 14:58:03 UTC
Rebased patch mentioned in comment 26 on master, updated the commit summary and merged. Thanks, Vitaliy.
Comment 28 Siebrand Mazeland 2013-01-11 16:22:12 UTC
IAlex proposed some more work in Gerrit change #43445. Please review.
Comment 29 Niklas Laxström 2013-01-20 14:54:36 UTC
Not fully fixed, see bug 43899.
Comment 30 Andre Klapper 2013-01-22 21:34:29 UTC
(In reply to comment #29)
> Not fully fixed, see bug 43899.

Gerrit change #43445 has not been merged yet; not sure though if that would fully fix this.
Comment 31 Alexandre Emsenhuber [IAlex] 2013-01-23 17:17:07 UTC
Proposed fix for this specific case in Gerrit change #45337.
Comment 32 Alexandre Emsenhuber [IAlex] 2013-01-23 20:50:10 UTC
Change merged.
Comment 33 Nemo 2013-03-04 19:32:29 UTC
Still has to be backported to 1.20 (for 1.20.4; it didn't make it to 1.20.3).
Comment 34 Alexandre Emsenhuber [IAlex] 2013-04-13 07:14:36 UTC
Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.
Comment 35 Nemo 2013-04-13 07:21:20 UTC
(In reply to comment #34)
> Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.

Ah, it would have been nice to know... This bug causes major disruption and now we have only 2 days to fix it on 1.19 and 1.20. :(
Comment 36 Andre Klapper 2013-04-13 13:29:36 UTC
rc tarball creation is not a good reason for "immediate" priority. Resetting.

(In reply to comment #34)
> Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.

The revert got merged on March 22nd, which means it's included in 1.22wmf1 which is now deployed everywhere since April 10th.

So has anybody run into the issue originally reported here in the last days?
Comment 37 Andre Klapper 2013-04-16 10:26:11 UTC
MatmaRex (comment 16), Niklas (comment 23):

Has any of you run into the issue in the last days again?
Comment 38 Bartosz Dziewoński 2013-04-16 11:19:14 UTC
I haven't heard any reports, no.
Comment 39 Siebrand Mazeland 2013-04-16 13:34:43 UTC
Not observed on since 14-Apr-2013 07:42:13 UTC.
Comment 40 Siebrand Mazeland 2013-04-16 13:35:31 UTC
(In reply to comment #39)
> Not observed on since 14-Apr-2013 07:42:13 UTC.

Oops. I need to clarify that: Logs go back to the above date and this particular issue is not in it.
Comment 41 Nemo 2013-04-16 13:38:24 UTC
The point is how to fix this in 1.20.x...
Comment 42 Andre Klapper 2013-04-17 09:41:56 UTC
Thanks. Currently no indicators that this still happens, hence decreasing prio/seve. Please bump up if this is seen again.
Comment 43 Andre Klapper 2013-05-30 13:21:42 UTC
(In reply to comment #41)
> The point is how to fix this in 1.20.x...

Mark: Any comments (or decision on the backport request flag)?
Comment 44 Mark A. Hershberger 2013-05-30 16:36:12 UTC
From what I can see from my brief review, this looks like mostly something that affected only TranslateWiki.  Are there other reports aside from scowiki and TWN?

If not, I don't think this is critical enough for a new release.
Comment 45 Tim Starling 2013-06-06 06:27:28 UTC
Regarding Title::getLatestRevID(): getArticleID(0) will get the article ID cached in the object, it won't necessarily be from the same transaction as the page row used in LinkCache. But staleness is expected with $flags=0 so it wouldn't be harmful to just pick a winner. I don't understand why an exception needs to be thrown.

With $flags=GAID_FOR_UPDATE, maybe there is a greater need for freshness, but in that case, LinkCache::addLinkObj() is done unconditionally by getArticleID() against the master, which should make absence from LinkCache impossible.
Comment 46 Gerrit Notification Bot 2013-06-06 06:52:51 UTC
Related URL: (Gerrit Change I0add48463341e56fe8c155b1007487278ad2705d)
Comment 47 Andre Klapper 2013-06-13 19:16:38 UTC
(In reply to comment #46)
> Related URL: (Gerrit Change
> I0add48463341e56fe8c155b1007487278ad2705d)

Patch got merged two days ago. Closing as FIXED.
Comment 48 Umherirrender 2013-07-12 18:18:05 UTC
*** Bug 41360 has been marked as a duplicate of this bug. ***

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