[00:00] That is the case. [00:00] So that makes complete sense. [00:00] The question is whether your case is the same. [00:01] It's the same cycle, but is it also caused by the object getting lost due to the reset. [00:01] Does http://paste.ubuntu.com/14059967/ help? [00:01] It's a set. [00:01] It certainly shouldn't. [00:01] Oh, so it is [00:02] In the garbage runs there is no case in which unhook is called from within MutableValueVariable. [00:02] Even if it were only added once, it would still leak. [00:02] * wgrant looks for any reset hooks. [00:03] Ah [00:03] There are none. [00:03] invalidate probably won't cause this, since it does _mark_autoreload [00:03] Right, exactly. [00:03] abort does invalid, which does AutoReload. [00:03] Which is why this normally works. [00:03] We reset between tests, but normally abort or commit first. [00:04] Look at Store.reset -- it just clears the dicts. [00:04] Yeah [00:04] With a "beware" comment at the top [00:04] Hm, but the object itself is presumably destroyed. [00:04] Its destructor could tell its variables to GTFO, presumably. [00:04] But ew __del__ [00:05] I wonder how slow it would be to fire hooks on them all as they are reset... [00:05] I was wondering whether the tp_traverse implementation might be incomplete [00:06] Hmm. [00:07] Isn't the cycle legitimate? [00:07] Or does PostgresConnection not refer back to the event_system? [00:08] What would the tp_traverse bug be? [00:09] Missing MutableVariableValue._event_system, possibly. Just trying without C extensions to narrow it down [00:09] Ah, possibly. [00:10] OK, still garbage from that, so probably a red herring. [00:15] (Pdb) p gc.get_referents(gc.garbage[0])[0]['_event'] is gc.get_referrers(gc.garbage[0])[1]['_event'] [00:15] True [00:15] gc.garbage[0] is the PostgresConnection [00:15] So looks legit to me. [00:15] Unless we can remove a reference or use a weakref, it's uncollectable. [00:16] Hm, can we weakref the hook, I wonder. [00:16] Presumably if the object is still known by the store, its variable will still be alive. [00:16] We only need to detect changes if we're possibly going to flush them to the store, so if we're no longer in the store it's irrelevant. [00:16] Right? [00:16] Yeah, and quite a few other hooks are weakreffed [00:16] Oh are they [00:17] So they are [00:17] Well [00:17] Their args are [00:17] Maybe not a perfect example [00:17] Hmmm actually. [00:18] This may not be valid. [00:18] What if I have the object, query 10 million other objects so it's evicted from Storm's cache, then change the mutable value, delete my reference, then flush. [00:19] It's a little hard to see how to get away without a reset hook. [00:20] Heh and even the reset hook isn't sufficient here, I don't think. [00:20] Oh, unless it keeps weakrefs to even evicted objects. [00:20] In which case it would. [00:20] s/unless it/unless the Store/ [00:20] Cache eviction could call a hook too. [00:20] But starts to sound rather slow. [00:21] It'd also be a weird hook [00:21] Basically a "leak pls" hook. [00:21] Or a "make changes not work" hook [00:21] Because we can't unhook _detect_changes just because the object is evicted; it may be alive elsewhere. [00:21] Yeah [00:22] Ah [00:22] _alive is a WeakValueDictionary. [00:22] _cache is separate. [00:22] So a reset hook may work. [00:23] It also can't be any slower than an abort. [00:23] I have to go to sleep, so will pick this up in the morning if you haven't figured it out by then ... [00:23] Oh of course it needs _alive. Even if it's evicted from the cache it has to use the same object if it's reretrieved by key. [00:23] I might end up wrapping our stores, will see. [00:24] Or just replacing all our reset calls, short-term. [00:24] The possible slowness would be in having to go and look for hooks on ten million objects. [00:24] Right, but abort and commit already do that. [00:24] And we already do that for every test. [00:24] Outlawing reset would probably be a reasonable stopgap. [00:24] It's terrible, but already done. [00:25] Well, outlawing it without an immediately previous abort/commit [00:26] There aren't too many of those [00:26] Anyway, sleeeeep [00:27] Yup,. [00:27] Night, thanks for investigating. [00:58] Trying to work out why I need that Milestone construction in there. [00:58] The test doesn't leave garbage unless I've created something else referring to that object since the last commit. [01:03] http://pastebin.ubuntu.com/14060983/ on top of trunk is minimal so far. [05:35] cjwatson: I suspect that http://paste.ubuntu.com/14071248/ will be sufficient. [05:35] It turns out that object-deleted often doesn't get called at all, because it's only invoked by a weakref callback. [05:35] And the objects can sometimes outlive the weakref callbacks. [05:35] s/weakref callbacks/weakrefs/ [05:36] (obviously the callback would never be invoked anyway in the uncollectable circular case, but removing the hooks also seems to eliminate at least one case of uncollectability. so hopefully it's enough) [11:11] wgrant: I'm trying a full test run with that patch now. Shall I land it if it checks out? [11:11] cjwatson: Or even before it checks out, if you're so inclined. [11:11] The Storm test suite passes with it. [11:11] And it's not obviously terribly wrong. [11:12] Can you commit it to our Storm branch and I'll sort out an sdist build and an LP landing? [11:12] I agree it seems at least plausible. [11:13] We may need to detach a couple of extra hooks in the deletion hook, but this fixes at least one case. [11:13] If it goes well I'll also merge storm trunk tomorrow, as it fixes that restricted librarian "Processing failed" thing that we run into occasionally. [11:16] Oh? What was the change there? [11:16] r466? [11:19] If that's the thing about making "cannot send data" ish a DisconnectionError, yes. [11:19] Yeah, that [11:19] Pushed up to revision 408. [11:19] 3 tags updated. [11:19] oh no bzr what did you do [11:20] wgrant: http://paste.ubuntu.com/14072599/ if that helps [11:20] I was hoping you'd say that. [11:21] 0.20 free.ekanayaka@canonical.com-20130628093022-ztq82k68kepzznxx [11:21] Be glad I didn't reflexively "bzr up" first. [11:21] And two lds tags [11:21] Hm. [11:21] I wonder if I tried a merge into it at some point and it remembered the tags. [11:21] Harmless, anyway. [11:21] Presumably those are ghosts with respect to our branch, but in the same repository. [14:41] Total: 19377 tests, 0 failures, 0 errors in 195 minutes 26.711 seconds. [14:41] good sign [16:16] Yay, buildbot happy again. [16:16] wgrant: thanks! === mgz is now known as mgz_ === xnox is now known as xnox_2016 [21:47] Oh good, buildbot works. [22:02] Something has to (probably). [22:02] Indeed...