341893 - Session restore caused increased leakage on balsa

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Adam Guthrie]

During this check-in range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006%3A06%3A16%3A10%3A11%3A00&maxdate=2006%3A06%3A16%3A11%3A34%3A00&cvsroot=%2Fcvsroot
leaks increased on balsa, leaking XPCWrappedNative objects.

biesi says that usually JS is to blame for leaking this type of objects, so blame goes to session restore.

Comment 1

[Dietrich Ayala (:dietrich)]

Yep, session-restore was enabled at 10:48:52, and Lk on balsa increased about 0.7% in the subsequent builds.

However, I think this is distinct from the 3% increase in Lk that occurred about 5 hours later:

http://build-graphs.mozilla.org/graph/query.cgi?tbox=balsa&testname=trace_malloc_leaks&autoscale=1&size=&units=bytes&ltype=&points=&showpoint=2006%3A06%3A16%3A17%3A57%3A13%2C407283&avg=1&days=2

The check-in list for that window:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&maxdate=1150509578&mindate=1150505880

I'll use this bug to track the session-restore leak, and will file a separate bug for the later increase.

Comment 2

[Adam Guthrie]

I guess you could file a separate bug for it. I'm currently trying to blame Peter Kasting for it in bug 209989.

Comment 3

[Adam Guthrie]

Leaks increased again for the landing of the splitting into two services. I guess we'll cover that here, too...

2472	MOZ_CO_DATE=2006:06:17:17:36:00
2528	MOZ_CO_DATE=2006:06:17:18:43:00

Checkins:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006%3A06%3A17%3A17%3A36%3A00&maxdate=2006%3A06%3A17%3A18%3A43%3A00&cvsroot=%2Fcvsroot

Leak logs say we're leaking an XPCWrappedNative again.

Comment 4

[Dietrich Ayala (:dietrich)]

Fixing bug 343659 was expected to fix some leakage. However, lk didn't change on branch. On trunk, lk went down, but given that branch didn't move, it's likely from bug 343417, which was checked in around the same time.

Comment 5

[Mike Connor [:mconnor]]

This seems to have been another bug, which is fixed1.8.1, not blocking.

Comment 6

[Adam Guthrie]

Dietrich, I want to close this bug, but I'd like be sure session store isn't leaking. Is there a way I can simulate session store not being "active"; e.g. not even loading the component? This way I can test with and without session store "enabled".

Comment 7

[Dietrich Ayala (:dietrich)]

(In reply to comment #6)
> Dietrich, I want to close this bug, but I'd like be sure session store isn't
> leaking. Is there a way I can simulate session store not being "active"; e.g.
> not even loading the component? This way I can test with and without session
> store "enabled".
> 

set browser.sessionstore.enabled = false and restart. The components load, but basically do nothing.

Comment 8

[Adam Guthrie]

OK. I tested for a while both with and without session restore enabled and didn't see a difference in leaks. Resolving as WORKSFORME.

Comment 9

[Dietrich Ayala (:dietrich)]

(In reply to comment #8)
> OK. I tested for a while both with and without session restore enabled and
> didn't see a difference in leaks. Resolving as WORKSFORME.
> 

Thanks Adam!