Lucas_Werkmeister_WMDE added a comment.

So I temporarily added a few debug statements (only long enough for me to make one web request, then removed again immediately), and it seems that adding this right after the wbsearchentities definition in Wikibase.php (L251)

file_put_contents( '/tmp/wbsearchentities-factory', var_export( $wgAPIModules['wbsearchentities']['factory'], true ) );

and this after WikibaseRepo.entitytypes.php is loaded in WikibaseRepo::getDefaultEntityTypes (L560)

file_put_contents( '/tmp/item-content-handler-factory-callback', var_export( $repoEntityTypes['item']['content-handler-factory-callback'], true ) );

makes the wiki work again. Somehow. (It seems to be reliable – I tried adding and removing them about ten times, and each time the wiki went from broken to working back to broken.)

The reason I added those debug statements was that I suspected the interpreter was mixing up closures, and I wanted to see if these two were dumped with the same ID (e. g. Closure$#5;2604). But it looks like those statements are actually enough to fix the bug, somehow. If my suspicion is correct (which could also explain the stack overflow in the initialization – there’s a closure in that stack trace too), I suppose it’s possible that printing a closure is enough to stop the interpreter from mixing them up, perhaps because it causes some kind of deoptimization or something… does this sound at all plausible?

Counterpoint: as far as I can tell from /var/log/dpkg.log*, HHVM hasn’t been upgraded on that host since February 8th, so if this really is an interpreter bug you’d think it should have started to happen sooner. So this theory definitely doesn’t provide a complete explanation yet as to how this problem came to be.



To: Lucas_Werkmeister_WMDE
Cc: WMDE-leszek, daniel, hoo, aude, Ladsgroup, Addshore, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Luke081515, Wikidata-bugs, Mbch331, Jay8g, Krenair, greg
Wikidata-bugs mailing list

Reply via email to