The number of allocations on balsa went from a 206K to 239K last night between 4 and 6pm. The checkins in range are http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1144362540&maxdate=1144372319&cvsroot=%2Fcvsroot possibly except for mrbkap that checked in before the 206K run. The increase can easily be seen on this graph: http://build-graphs.mozilla.org/graph/query.cgi?testname=trace_malloc_allocs&units=count&tbox=balsa&autoscale=1&days=7&avg=1&showpoint=2006:04:06:17:58:38,244827 (you may have to adjust the number of days displayed since the graphtool is crappy).

Bug 330063 and bug 330842 looks most suspect since mrbkaps checkin happened before the increase, and bug 45715 looks like it should only affect thunderbird

looks like refcount leaks jumped as well at the same time http://build-graphs.mozilla.org/graph/query.cgi?testname=refcnt_leaks&units=bytes&tbox=balsa&autoscale=1&days=7&avg=1&showpoint=2006:04:06:17:56:10,2180

The only part of the patch for bug 330063 that would apply to normal startups would be the change to using an nsIDirectoryEnumerator.

Gavin: That would leave your patch then. Could you try to back it out to see if it brings the numbers back down.

Sorry, I meant "The only part of the patch for bug 330842 that would apply to normal startups would be the change to using an nsIDirectoryEnumerator."

I'll look for any potentially culpable code in 330063 in the next 24 hours...

Just remember that you'll have to be able to at least back out and test if your code was it. I.e. it gets complicated if other people check stuff in on top of your patch.

OK, looks like my 330063 was the culprit--I rolled that back on branch & trunk, and the balsa numbers went back down, so I'm marking this fixed.

Thanks!

Note that it is ok for the numbers to go up a bit, it just felt like a lot unless it is a really major change. Also the leak numbers went up which is bad.

After spending some time digging into this issue, I've figured out a lot more about what happened here. The rise in allocations is because patch 330063 uses nsILivemarkService to configure the livemarks in the toolbar and menu, and previously the actions in the bloat test didn't do anything that instantiated the Livemark Service. (The pre-330063 code was observing the livemark annotations via the nsIAnnotationService, rather than the cleaner methods that 330063 add to the Livemark Service.) When the changes caused the Livemark Service to be instantiated on branch balsa, the bloat test brought to light some previously-unnoticed reference leaks in nsLivemarkService::Init(), which I fixed in bug 333764 and bug 333784. I just checked in the latter, and assuming everything cycles green, I'm going to resubmit the changes in bug 330063 tonight and watch branch balsa to verify that the ref leaks have been resolved.