Created attachment 747582 [details] DMD report for Layer::SetAnimations In fact, Layer appears to have no memory reporter at all. DMD reports two allocation stacks including the following line representing about 2.4mb of memory on B2G (on a long-running session): css::ComputedTimingFunction* ctf = new css::ComputedTimingFunction(); A slice of the DMD report: mozilla::layers::Layer::SetAnimations(...) mozilla::layers::ShadowLayersParent::RecvUpdate(...) nsTArray_base<nsTArrayInfallibleAllocator>::Length() const mozilla::layers::PLayersParent::OnMessageReceived(IPC::Message const&) mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const&) (Length() isn't present in the second stack, but otherwise it looks the same.) This timing function is getting put into Layer::mAnimationData. In bug 870436, there's also about 6mb of unreported image data sitting around. Could we somehow be leaking animation somehow (not knowing anything about layers or images)? I don't have the about:memory information for that bug yet, so I'm not sure where the rest of the memory is going. This is based on a DMD report from bug 870319, where a Unagi run for 24 hours with the monkey tester isn't able to open the home screen any more, probably indicating a leak.
jlebar said there was a recent patch that fixed leaks with these data structures, so we should figure out if that was fixed here, because if it was, we probably have another leak.
Bug 856080 landed on b2g18 and b2g18-1.0.1 on April 30th. I think this build is May 8th. The report claims Build: sp8810eabase_512x256_hvga-eng 184.108.40.206.4.0.4 OPENMASTER eng.apuser.20130508.210210 test-keys
> I think this build is May 8th. It is /possible/ that they didn't build the tip of branch. I agree, they would have had to pull a pretty old cset, but the DMD report is exactly the same... Anyway if this is still leaking, that's very bad, I think.
Per bug 870319 comment 9, they were using an old Gecko. One bug down...