New issue
Advanced search Search tips

Issue 804440 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Potential memory leak in WebRTCInternals::OnGetUserMedia.

Project Member Reported by erikc...@chromium.org, Jan 22 2018

Issue description

OS: macOS 10.13.2
Chrome: 65.0.3318.0

We've observed [sampling from a real user using out-of-process heap-profiling], ~5 million calls to malloc/new without a corresponding free/delete that originate from this function. These objects occupy ~263MB of memory. 

I've attached a symbolized trace. Looking at the code, it looks like get_user_media_requests_ potentially grows without bounds. Is there some type of pathological scenario that could cause this? Would it be reasonable to have a max number of user_media_requests? 

[Note: for privacy reasons, we do not have further browsing/repro information - we only know that this has occurred for a real user]. 
 
trace-c096f20da18ab778.gz
214 KB Download

Comment 1 by guidou@chromium.org, Jan 23 2018

Components: -Internals>WebRTC -Blink>WebRTC Blink>WebRTC>Tools
Cc: hta@chromium.org
Owner: guidou@chromium.org
Status: Assigned (was: Untriaged)
Guido, can you take a look at this?
I've attached a screenshot which shows the allocating stack trace, total size of all live allocations, and # of live objects.

For instructions on how to use the symbolized trace, see https://chromium.googlesource.com/chromium/src/+/lkcr/docs/memory-infra/heap_profiler.md.
Screen Shot 2018-02-16 at 11.16.57 AM.png
309 KB View Download

Comment 4 by guidou@chromium.org, Feb 19 2018

Labels: -Pri-1 Pri-2
Elements of |get_user_media_requests_| are removed when the corresponding renderer process terminates.
The only case where they wouldn't be released is if the RenderProcessHost object for the renderer process didn't exist and didn't notify about the exit of the renderer process.

Maybe the user who had this problem just issued a lot of getUserMedia() requests and never closed the tab?

Lowering priority to 2, since this is not a regression and, in principle, does not look like an actual bug.

Comment 5 by guidou@chromium.org, Feb 19 2018

Labels: Needs-Feedback
So to clarify, if I make a website that makes lots of getUserMedia() requests, and the user never closes the tab [which we appear to be observing in the wild], this will cause the browser process to potentially bloat without limit?

Can we add some type of reasonable limit, or clear out | get_user_media_requests_| prior to process termination? 
Project Member

Comment 8 by bugdroid1@chromium.org, Feb 20 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/645fc9813911acbae34125377fbb4bf5b0494b07

commit 645fc9813911acbae34125377fbb4bf5b0494b07
Author: Guido Urdaneta <guidou@chromium.org>
Date: Tue Feb 20 19:46:03 2018

Limit to the number of getUserMedia() requests tracked by webrtc-internals

Tracked requests are normally removed when the corresponding renderer
process dies.
However, it has been reported that this mechanism could be used to launch
a DoS attack against the browser process, resulting in "leaks".

This CL sets a limit of 1000 tracked gUM requests, which is a number
probably beyond what is practical for the webrtc-internals UI anyway.

Bug:  804440 
Change-Id: I578fbb4ab6feee17f035beca2dbec86381376b6c
Reviewed-on: https://chromium-review.googlesource.com/926366
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Tommi <tommi@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537850}
[modify] https://crrev.com/645fc9813911acbae34125377fbb4bf5b0494b07/content/browser/webrtc/webrtc_internals.cc

Comment 9 by guidou@chromium.org, Feb 21 2018

Status: Fixed (was: Assigned)
Labels: -Needs-Feedback Hotlist-HeapProfilingInField

Sign in to add a comment