getUserMedia leaks a lot of memory, especially with screen sharing

NEW
Assigned to

Status

()

Core
WebRTC: Audio/Video
P4
normal
Rank:
35
4 years ago
7 months ago

People

(Reporter: florian, Assigned: jesup)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox33- affected, firefox34- affected)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
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.
(Reporter)

Updated

4 years ago
Blocks: 1040061
(Assignee)

Comment 2

4 years ago
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: --- → +
Whiteboard: [MemShrink] → [MemShrink:P2]
Randell, any news on this? Thanks
Flags: needinfo?(rjesup)
(Assignee)

Comment 5

4 years ago
[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: + → ?
Flags: needinfo?(rjesup)
OK. Thanks for the input!
tracking-firefox33: ? → -
tracking-firefox34: ? → -
Blocks: 923225
No longer blocks: 1040061
Rank: 35
Priority: -- → P3

Updated

3 years ago
backlog: --- → webRTC+
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.