406914 - Last cycle collection happens while we have live JSContexts

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect, P4)

Description

[Boris Zbarsky [:bzbarsky]]

See bug 391318 comment 31.  I think this is causing at least some of the leaks in that bug.

Comment 1

[Robert Kaiser]

Any progress on how to fix this or an actual patch?

Comment 2

[Mike Schroepfer]

Ping on this

Comment 3

[Mike Schroepfer]

Sicking - b3 or beyond?

Comment 4

[Johnny Stenback (:jst)]

I really don't think this is worth worrying about for ff3 any more, nor is this something that I would want anyone to touch this late in the game either. Clearing blocker and priority flags.

Comment 5

[Robert Kaiser]

Bummer. That means SeaMonkey is condemned to ship a final with a known 9K leak (see dependency). Yay for core/toolkit development not caring about anything else than Firefox :(

Comment 6

[Peter Van der Beken [:peterv]]

I think messing with that shutdown sequence is risky. Furthermore, there was a bunch of debugging in bug 391318 and it's not clear to me at all that this would fix that leak. I did try to help in bug 391318 and so did bz, so I think you should be very careful with comments like comment 5.

Comment 7

[Johnny Stenback (:jst)]

I really don't want to touch this in a dot release. Marking wanted-next.

Comment 8

[Robert Kaiser]

This is possibly the cause for mochitest and mochichrome staying orange with leaks on hg-based SeaMonkey now.

Comment 9

[Robert Kaiser]

peterv, jst:
Is there a chance we can get this in 1.9.1?

Bug 391318 comment #31 and following strongly suggest that the issue reported here is the true cause of at least a major part of the leaks we're seeing, but it's hard to see if there's something else as well with the noise from this.

Our fiddling around with leak thresholds in bug 450983 to get some sort of green reporting from our test boxes, which have been orange with leaks for some time (bug 448125) comes back to the uncertainty of which leaks come from this issue and which don't. Additionally, that leak-caused orange has made it easy not to spot real test failures as orange is orange, no matter how many tests fail, leak or otherwise. Thresholds should improve that a bit, but fluctuating leak numbers from this issue make it hard to detect new leaks and failures at once, clearing out those leaks would surely be the preferred variant.

Comment 10

[Peter Van der Beken [:peterv]]

(In reply to comment #9)
> Bug 391318 comment #31 and following strongly suggest that the issue reported
> here is the true cause of at least a major part of the leaks we're seeing

I could be mistaken, but I don't think that's true. I think this bug is a side-effect from some JS code causing a leak. I'd strongly suggest trying to figure out the exact cycles in bug 391318. I know it's hard and a lot of work, but someone will have to do it.
Unless bz thinks this is an important issue that needs to be fixed regardless (why?), this is not a priority for me.

Comment 11

[Johnny Stenback (:jst)]

Not going to block 1.9.1 on this. If someone signs up to do the work to find the actual leak that peterv talks about above, or prove that the cause of this is something else, then we'd certainly accept a safe patch.

Comment 12

[Robert Kaiser]

The investigations on the SeaMonkey leak have been moved to bug 470709 now, it looks like we would be holding on to the actual sources of the data referenced by that XUL datasources attribute in that case (which are the extensions component and localstore datasources).
Are we not collection the RDF cache until too late or something like that?

Comment 13

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.