826538 - DOMWINDOW leaks if window reloads shortly after call to GetUserMedia

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P1)

Description

[Adam Roach [:abr]]

Attachment: Test case demonstrating the resource leak issue

See attached test case, which reliably leaks DOM windows (one per reload iteration).

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

I verified the windows are not leaking the activeWindows list of MediaManager.  Also, if you try the dropdown, it flashes for me (in remote X11), and the flash gets longer and longer, implying the windows are somehow leaking there. I'm going to check the EnumerateRead length for returning the window list to the UI

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

I checked - we never return more than 1 window in from GetActiveMediaCaptureWindows(), but the list seemed to keep growing in the UI.  I hit the bug with null gGraph however when I tried to pull down the list, though.  At this point it appears we're never telling the UI about more than 1 window at any given time, and we're not holding window ptrs, so far as I can tell, in MediaManager/gUM.  Perhaps they're leaking in the UI when we get reloaded while a request is in process to the UI, or when the active window list is being fetched.

Comment 3

[Nicholas Nethercote [inactive]]

jesup, any progress here?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

bz: is a temporary accumulation of DOMWindows (which get destroyed when we navigate away from this link) to be expected?  I suspect the answer is yes...  in which case this bug can be closed as INVALID (or if the memshrink people think there's something still to address, reassigned to another component).

Dropping from blocking-gum because it does clean up and the tested case is non-useful in practice.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I would expect windows to go away as needed on gc here.  Are they not doing that?

Comment 6

[Andrew McCreight [:mccr8]]

I'll look at it to try to figure out if this is something we should worry about it.

Comment 7

[Nicholas Nethercote [inactive]]

mccr8: I'm guessing you haven't had a chance to look at this yet?

Comment 8

[Andrew McCreight [:mccr8]]

Yeah, sorry.

Comment 9

[Nicholas Nethercote [inactive]]

Does this still happen?

Comment 10

[Marco Castelluccio [:marco]]

Bug 925208 is probably related.

Comment 11

[Eric Rahm [:erahm]]

Are we still seeing this?

Comment 12

[Adam Roach [:abr]]

(In reply to Eric Rahm [:erahm] from comment #11)
> Are we still seeing this?

I don't think so. If I do some crude window counting like this:

NSPR_LOG_MODULES=DOMLeak:4 firefox 'https://bug826538.bugzilla.mozilla.org/attachment.cgi?id=697724' 2>&1 | perl -ne '/created/&&$c++;/destroyed/&&$c--;print "$c windows\n"'

Then I see the count climb up to about 200, and then fall and bounce around between 40 and 90. The previous symptom here was that the count of windows would grow without bound until you closed the tab.