[13:08:58] hashar: Glad I could help. I'm looking forward to seeing what results the core dump gives us. [13:10:07] anomie: I have no idea what the core could let us learn though :^\ [13:10:42] meanwhile I have send another patch that adds some more debug, notably log the array at the momment of its creation [13:10:42] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/536580/2/includes/libs/rdbms/lbfactory/LBFactoryMulti.php [13:10:53] Hopefully it'll point us to the bug in PHP that's making this happen. [13:11:07] with some weird assertion ('' === ILoadBalancer::GENERIC_MODE) which should always be true [13:11:34] and I have looked at the git log for php-src/ext/opcache but could not find anything meaningful :-\ then it is not like I know anything about the Zend optimizer jargon [13:14:59] I doubt it'll be so obvious, but if we see something like that the key is suddenly "\0" that would be progress. [13:20:44] anomie: maybe yes, so I am willing to give a try ;D [13:21:20] or it is a weird thing such as the constant empty string is optimized differently than '' and they mismatch [13:21:24] who knows :-\ [13:21:28] and obviously, can not reproduce [13:48:10] hashar: I'm a bit concerned that the train is blocked on this. I wonder if we could unblock the train by (temporarily?) setting the constant to some value other than the empty string, instead of waiting for a fix to whatever C code is at fault. [13:49:47] anomie good point yes [13:50:04] hoping that is not serialized in our caches somewhere [13:50:14] or maybe not it is not an issue [14:12:56] oh but Tim did post an analyze https://phabricator.wikimedia.org/T232613#5490569 [14:26:49] I just saw that. That makes it seem less likely that we'll find anything useful from the extra data, but we may as well try it anyway. [15:13:32] is this a php7.2 issue or a php5.x issue? [15:13:34] or a hhvm one? [15:13:51] subbu: 7.2 I believe [15:14:11] tangential question then: is this related to php 7.2 gc bug? [15:14:21] https://phabricator.wikimedia.org/T228346 [17:49:32] * @deprecated Removed in 1.27. Use PasswordReset instead. [17:49:54] Helpful comment when the thing doesn't have something to replace the code [17:51:05] what thing? [17:51:13] User::setNewPassword [17:51:17] Only used by OpenID [17:51:22] public function setNewpassword( $str, $throttle = true ) { [17:51:22] throw new BadMethodCallException( __METHOD__ . ' has been removed in 1.27' ); [17:51:22] } [17:52:31] tgr: Oh, it's your commit ;P [17:52:31] https://github.com/wikimedia/mediawiki/commit/3617c982c9db793515818e1468fa827ae5880358 [17:52:36] not sure why PasswordReset is mentioned there [17:52:49] it should be replaced by User::changeAuthenticationData probably [17:52:51] lol [17:54:46] While it's not been marked as wfDeprecated()... [17:54:48] oh, right, setNewpassword sets the temporary password, not the normal one, right? [17:54:52] or used to [17:54:59] seemingly, based on the usage in OpenID [17:55:07] if ( $user->checkPassword( $password ) ) { [17:55:07] // de-validate the temporary password [17:55:07] // requires MediaWiki core with https://gerrit.wikimedia.org/r/#/c/96029/ merged 2013-11-18 [17:55:07] $user->setNewPassword( null ); [17:55:22] yeah that functionality is more or less equivalent to what PasswordReset does [17:55:54] but you can use changeAuthenticationData with a TemporaryPasswordAuthRequest [17:56:48] if OpenID uses AuthManager, it shouldn't have to deal with it at all, temporary passwords are always removed on credentials change [17:57:19] It seemingly doesn't [17:57:33] Doesn't use extension registration [17:58:22] TBH, I can't imagine OpenID works on master MW anyway [17:58:36] why care then? if it uses an unsupported auth framework it is on its own [17:58:48] Well, that's what I'm wondering [17:58:57] So we can just remove the function from core and carry on with our lives [17:59:18] Latest version 4.4.0 (2014-04-01) [18:00:11] it doesn't work anyway, has been deprecated four years ago, sure [18:00:28] I wonder why we're letting translators still translate [18:01:23] if someone really wanted to make it work with AuthManager without actually updating it to use AuthManager, they'd have to do basically the same thing as User::changeAuthenticationData does, except use ACTION_REMOVE, not ACTION_CHANGE [18:01:59] but it would make little sense, external auth extensions use a whole host of hacks that they can get rid of when they update to AuthManager [18:02:20] just drop a warning template on its wiki page saying it's unsupported, IMO [18:02:56] Release status: stable [18:02:57] lol [18:04:19] https://www.mediawiki.org/w/index.php?title=Extension%3AOpenID&type=revision&diff=3406042&oldid=3104215 [18:04:36] Or is unstable better [18:04:58] astable. [18:05:06] Flip-flopping between different states. [18:05:11] https://www.mediawiki.org/wiki/Extension_status [18:05:53] https://gerrit.wikimedia.org/r/536656 removes it from core [18:09:13] could as well wait a few weeks and make it 1.35 [18:09:30] I just made the task for deprecation kills for 1.35, which include that. [18:09:42] And all the other User methods like checkTemporaryPassword() [18:09:43] on second thought, it throws an exception anyway... [18:12:07] https://phabricator.wikimedia.org/T232864 doesn't have setNewpassword [18:14:56] Yeah, exactly. It's not wfDeprecated.. but it's been throwing an exception for many MW versions.... So it's hardly like it's worked for a long time [18:19:11] Oh, right, yeah, let's just kill it. [18:22:08] 19 in gate and submit.. [18:22:34] Welcome to "Wikibase". Population too many damn patches. [18:23:28] 1 is WikibaseMediaInfo [18:23:32] The rest are not wikibase [18:23:48] mostly MW core [18:24:00] The https://gerrit.wikimedia.org/r/q/project:mediawiki%252Fextensions%252FWikibase+is:merged+-age:6h [18:24:15] That's ~3 hours of CI lock-up just there. [19:05:22] anomie: The "isPrintable" check seems quite suspicious as well in that code path. Suggests that anything "printable" is never cacheable which seems weird. I was initially scared it might be the reserve (assume "printable" is always cacheable) but afiak that's not the case. [19:09:20] Krinkle: My wild guess is that it's more "it's not worth wasting cache space caching it". [19:11:57] Krinkle: Unfortunately http://mediawiki.org/wiki/Special:Code/MediaWiki/2440 doesn't seem to give us any answers. [19:15:58] anomie: turnilo/webrequest_128k sampled/past 24 hours: https://w.wiki/8KZ [19:16:09] ~ 12K out of 6 million /w/index.php requests [19:16:15] not much indeed [19:16:26] especially since the sidebar link is now primarily short-circcuted to window.print() [19:16:40] so it's only slow/broken/noscript Grade A browsers and Grade C [19:16:53] Apparently someone has a thing for elements. [19:17:25] Yeah, it is interesting why all of those are printed that often [19:17:32] printable-view'ed [19:17:58] I'd guess someone has code screen-scraping the pages for some reason.