[01:22:08] TimStarling: What approach would you recommend for trying to find the memory leak when developing locally? RE: https://phabricator.wikimedia.org/T31784 [01:23:53] one cute trick is to wait for it to use a lot of memory, then do a core dump, and open the core dump in a text editor [01:24:08] if it is leaking strings then you can easily see what strings are being leaked [01:25:02] if it's leaking objects, in PHP 5 it was possible to identify the object since every object stored a hashtable of members, so you would see the member names thousands of times [01:25:10] not sure if that is still possible in PHP 7 [01:26:43] for object leaks, you can use __destruct() to trace when an object is freed [01:27:37] I used this for RemexHtml, the challenge there was that it would create say 10000 objects, then free 9999, leaking 1, which means the core dump trick doesn't work very well [01:28:22] but with __destruct() printing a message or whatever, you could see exactly which objects are freed on exit, and which are freed when they are meant to be [01:28:42] the assumption here was that circular references were at fault [01:29:53] an easy way to make a core dump is to run the process under gdb, then use the "gcore" command [01:31:34] Don't we have some graphs and such on production too? [01:32:44] TimStarling: Ah, I like the __destroy trick. [01:32:47] I'll try both. Thanks! [04:59:55] TimStarling: RoanKattouw: Looks like I found the case - https://phabricator.wikimedia.org/T31784. Thanks again. [05:01:15] nicely done [05:02:48] btw because spl_object_hash() is so enormous and differs in hard-to-spot ways, I found it useful to use a substring of the md5 hash of it [05:02:57] see e.g. getDebugTag() here: https://github.com/wikimedia/mediawiki-libs-RemexHtml/blob/master/RemexHtml/TreeBuilder/Element.php#L177 [05:03:16] although hashes will still be reused after free, since the memory locations can be reused [05:03:27] the only way to avoid that is by using a static serial number [05:06:01] TimStarling: What about the number used by var_dump? Is that re-used? I wasn't sure at first. [05:06:16] Yeah, it looks quite similar. At first I thought they were all the same too. [05:06:20] gtg, bbl [05:09:17] pretty sure it is reused [05:09:50] I just checked the source to refresh my memory, HHVM doesn't have object handles, it just puts (0) in the var_dump() output for compatibility with unit tests [05:10:11] Zend has [05:10:16] if (EG(objects_store).free_list_head != -1) { [05:10:17] handle = EG(objects_store).free_list_head; [05:10:26] which is apparently that integer being reused [07:50:56] AaronSchulz: if I remove the logging from rollbackMasterChangesAndLog...there's not really a point to having that method any more. callers could just rollback via the lbfactory [07:53:56] why would you remove it? There was a suggestion to not use the Bug* channel and use the regular one. [07:55:20] AaronSchulz: maybe I misunderstood your comment, I just added a 'uncommitted_changes' property to getLogContext() and was just going to make sure all callers also called logException() [20:59:55] RFC meeting starting now in #wikimedia-office: Consider changing wikipage redirects to be proper HTTP redirects [21:29:29] legoktm: Heh, speaking of logging: https://phabricator.wikimedia.org/P5647 [22:01:58] Am I correct in guessing that Renameuser is redundant to CentralAuthRename now? [22:02:18] anomie, tgr: have you seen https://phabricator.wikimedia.org/T168802 ? [22:04:23] RainbowSprinkles: CentralAuth's rename class Renameuser internally [22:05:06] Ah boo [22:05:13] I'm trying to clean some of this logging crap up [22:12:04] OCG has failed 2500 times in the last 18 hours. Does it ever work? :p [22:12:13] 2538, to be specific [22:14:29] might be exaggerated due to long log lines being split up [22:14:34] pfft, ocg is dead man walking [22:15:10] I looked at the lines [22:15:17] This isn't multi-line errors :) [22:15:29] MaxSem: I've got a shotgun....can hurry things along.... [22:15:39] (and by shotgun I mean text editor with the config repo open in it) [22:17:14] Seriously, what freaking device can't do its own print-to-pdf crud by now? And if it's that ancient: how is it even hitting WMF sites anymore with such an outdated TLS stack? [22:18:17] MaxSem: maybe just change the test config to use the default DB and change the setup code in CA to skip the manual table generation when it is set to use the default DB? [22:18:20] (And yes, our print stylesheets suck, but we should fix that anyway....) [22:18:59] RainbowSprinkles: yeah, we are working on both of those [22:19:19] Well the former is just disabling something :p [22:21:53] tgr, the thing is that local DB isn't supposed to have the CA tables in the first place. right now, I'm trying this: https://gerrit.wikimedia.org/r/362098 [22:22:09] however, our tests are just so fucking fragile... [22:22:30] I just don't know if other explosions on the horizon are from CA or something else [22:22:30] RainbowSprinkles: depends on how large an angry mob you want before your door by next morning [22:22:50] to be fair, OCG does a couple things in-browser print can't [22:22:56] and CA changes themselves pass testing anyway... [22:23:10] like multi-article books and page numbers [22:23:22] ooooooh, page numbers [22:23:28] (which most printers can also do) [22:23:39] * RainbowSprinkles thinks he could handle a mob [22:24:36] printers can put the numbers on the bottom of the page (although it tends to look horrible) but not in the table of contents [22:25:03] that's pretty much what the replacement project is stuck on ATM [22:25:17] * RainbowSprinkles regrets bringing this up [22:25:40] Fwiw, there's probably some ancient mailing list post from me a long time ago saying this was a silly idea before it even got this far ;-) [22:26:16] tgr, whatdo you think of my attempt? [22:29:21] MaxSem: looks sane