728230 - Adding a bookmark and opening a new window and closing the old one causes runtime leaks

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

We leak the browser.xul of the old window.
JS implemented nsITransaction keeps it alive.

This adds the CC time significantly.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

STR:
start FF
load a page which hasn't been bookmarked.
click the star twice, click done.
open a new window
close the old window.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

(Btw, once Bug 726346 is fixed, you can install the addon from that bug.
Then after STR load about:cc
run CC and search for the name nsDocument.
Then take the address of that and search for roots and you get nsITransaction)

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

If I read the logs correctly, we seem to leak the window at least via uri wrapper

0x7faa56040160 XPCWrappedNative_NoHelper 7faa579a44e0
> 0x7faa5472df40 type
> 0x7faa5471d448 shape
> 0x7faa56040130 XPCWrappedNativeProto::mJSProtoObject
> 0x7faa5c5d04c0 XPCWrappedNativeScope::mGlobalJSObject
> 0x7faa5c568bc0 XPCWrappedNativeScope::mPrototypeJSObject
> 0x7faa54700640 equals
> 0x7faa547007c0 schemeIs
> 0x7faa547c5c40 clone

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: dumb hack

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

working on a better patch.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: patch v1.0

a bit larger than I was expecting, but I ended up refactoring it to reduce possibilities of future leak regressions. All data is handled through a common object that enforces copying.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 598413 [details] [diff] [review]
patch v1.0

I can't see any change. The document is still there and kept alive by
nsITransaction

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I have found the remaining problem, it's the annotation object we create in browser-places, so I'll also have to copy those :(

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: patch v1.1

I tested this with your about:cc add-on, before the patch I see the browser.xul leak, after the patch it tells me no documents have been leaked.

The test coverage is given by test_placesTxn.js, that is a sucky test for the way it's written, but gives good coverage, I tried to avoid behavior changes as far as possible to reduce regressions, though the sooner we land the more testing we get, it's hard to get 100% coverage here.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 598519 [details] [diff] [review]
patch v1.1

Seems to work now. Thanks!

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: patch v1.2

a test was correctly failing, I identified an unwanted behavior change and this restores it.

Comment 12

[Dietrich Ayala (:dietrich)]

Comment on attachment 599606 [details] [diff] [review]
patch v1.2

Review of attachment 599606 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/places/PlacesUtils.jsm
@@ +2342,5 @@
> +  name: null,
> +  _transactions: null,
> +  set childTransactions(val) this._transactions =
> +    (val && Array.isArray(val) ? Array.slice(val) : null),
> +  get childTransactions() this._transactions,

for clarity, should be transactions & _transactions or childTransactions and _childTransactions.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

changed to childTransaction, and cleaned up a bit those getters.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9a8c57be783

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/a9a8c57be783