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)
Core
WebRTC
Tracking
()
RESOLVED
FIXED
backlog | webrtc/webaudio+ |
People
(Reporter: abr, Unassigned)
Details
(Keywords: memory-leak, Whiteboard: [getUserMedia][MemShrink][blocking-gum-])
Attachments
(1 file)
(deleted),
text/html
|
Details |
See attached test case, which reliably leaks DOM windows (one per reload iteration).
Comment 1•12 years ago
|
||
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•12 years ago
|
||
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.
Updated•12 years ago
|
Whiteboard: [getUserMedia] → [getUserMedia][MemShrink]
Updated•12 years ago
|
Whiteboard: [getUserMedia][MemShrink] → [getUserMedia][MemShrink][blocking-gum+]
Updated•12 years ago
|
Assignee: nobody → rjesup
Priority: -- → P1
Comment 3•12 years ago
|
||
jesup, any progress here?
Whiteboard: [getUserMedia][MemShrink][blocking-gum+] → [getUserMedia][MemShrink:P1][blocking-gum+]
Comment 4•12 years ago
|
||
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-]
Comment 5•12 years ago
|
||
I would expect windows to go away as needed on gc here. Are they not doing that?
Comment 6•12 years ago
|
||
I'll look at it to try to figure out if this is something we should worry about it.
Assignee: rjesup → continuation
Comment 7•11 years ago
|
||
mccr8: I'm guessing you haven't had a chance to look at this yet?
Comment 9•11 years ago
|
||
Does this still happen?
Whiteboard: [getUserMedia][MemShrink:P1][blocking-gum-] → [getUserMedia][MemShrink:P2][blocking-gum-]
Comment 10•11 years ago
|
||
Bug 925208 is probably related.
Updated•10 years ago
|
backlog: --- → webRTC+
Rank: 15
Whiteboard: [getUserMedia][MemShrink:P2][blocking-gum-] → [getUserMedia][MemShrink][blocking-gum-]
Reporter | ||
Comment 12•9 years ago
|
||
(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.
Description
•