Created attachment 8472935 [details] dmd-unreported-webrtc-blocks.txt Using getUserMedia with the camera or microphone once keeps about 8MB of memory in heap-unclassified. Sharing a window keeps an additional 16MB of memory, and sharing the screen keeps an additional 100MB. Steps to reproduce: - With a DMD-enabled build, go to http://queze.net/goinfre/ff_gum_test.html, and use the Video, or Audio, or Window, or Screen button. - grant permission to use the device in the doorhanger - open a new tab with about:memory - close the ff_gum_test.html tab - in about:memory, click "minimize memory usage" - click "Analyze reports" Note: cleanly stopping the media streams by clicking the "stop" button of the webpage before closing the tab doesn't change the result. I'm attaching a txt file containing the unreported blocks that seem relevant to webrtc that I got in separate DMD runs after clicking the Video, Audio, Window and Screen buttons respectively. [Tracking Requested - why for this release]: large memory leak in a screensharing, a feature introduced in Firefox 33.
Created attachment 8472936 [details] Full DMD output for a run with screen sharing I have the DMD output for the other runs on my local disk, I can send them to someone if they are useful.
Some of these will be expected will-be-cleaned-up-on-exit (like the trace buffers) We can look at points where we can be more proactive about cleaning them up. I'll look into the others, thanks. (especially the new window/screen sharing leaks)
Assignee: nobody → rjesup
Users don't like memory leaks, I don't like memory leaks, tracking!
status-firefox33: --- → affected
status-firefox34: --- → affected
tracking-firefox33: ? → +
tracking-firefox34: --- → +
Randell, any news on this? Thanks
[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: This should not block. These operations do take considerable ram. The report "I'm attaching a txt file containing the unreported blocks that seem relevant to webrtc that I got in separate DMD runs after clicking the Video, Audio, Window and Screen buttons respectively." shows the major unreported blocks are normal webrtc allocations that get held until shutdown, not progressive leaks. we should file memshrink bugs for doing timed more-complete shutdown of webrtc as needed. Tracking set back to ? with a recommendation to remove
tracking-firefox33: + → ?
tracking-firefox34: + → ?
OK. Thanks for the input!
tracking-firefox33: ? → -
tracking-firefox34: ? → -
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.