Closed Bug 1053737 Opened 10 years ago Closed 4 years ago

getUserMedia leaks a lot of memory, especially with screen sharing

Categories

(Core :: WebRTC: Audio/Video, defect, P4)

x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox33 - affected
firefox34 - affected

People

(Reporter: florian, Assigned: jesup)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(2 files)

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.
I have the DMD output for the other runs on my local disk, I can send them to someone if they are useful.
Blocks: 1040061
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!
Whiteboard: [MemShrink] → [MemShrink:P2]
Randell, any news on this? Thanks
Flags: needinfo?(rjesup)
[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
Flags: needinfo?(rjesup)
OK. Thanks for the input!
Blocks: Screensharing
No longer blocks: 1040061
Rank: 35
Priority: -- → P3
backlog: --- → webRTC+
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: