Closed Bug 826538 Opened 12 years ago Closed 9 years ago

DOMWINDOW leaks if window reloads shortly after call to GetUserMedia

Categories

(Core :: WebRTC, defect, P1)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: abr, Unassigned)

Details

(Keywords: memory-leak, Whiteboard: [getUserMedia][MemShrink][blocking-gum-])

Attachments

(1 file)

See attached test case, which reliably leaks DOM windows (one per reload iteration).
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
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.
Whiteboard: [getUserMedia] → [getUserMedia][MemShrink]
Whiteboard: [getUserMedia][MemShrink] → [getUserMedia][MemShrink][blocking-gum+]
Assignee: nobody → rjesup
Priority: -- → P1
jesup, any progress here?
Whiteboard: [getUserMedia][MemShrink][blocking-gum+] → [getUserMedia][MemShrink:P1][blocking-gum+]
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.
Whiteboard: [getUserMedia][MemShrink:P1][blocking-gum+] → [getUserMedia][MemShrink:P1][blocking-gum-]
I would expect windows to go away as needed on gc here. Are they not doing that?
I'll look at it to try to figure out if this is something we should worry about it.
Assignee: rjesup → continuation
mccr8: I'm guessing you haven't had a chance to look at this yet?
Yeah, sorry.
Assignee: continuation → nobody
Does this still happen?
Whiteboard: [getUserMedia][MemShrink:P1][blocking-gum-] → [getUserMedia][MemShrink:P2][blocking-gum-]
Bug 925208 is probably related.
backlog: --- → webRTC+
Rank: 15
Whiteboard: [getUserMedia][MemShrink:P2][blocking-gum-] → [getUserMedia][MemShrink][blocking-gum-]
Are we still seeing this?
Flags: needinfo?(adam)
(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.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(adam)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: