Potential memory leak in WebRTCInternals::OnGetUserMedia. |
||||||
Issue descriptionOS: 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].
,
Jan 29 2018
Guido, can you take a look at this?
,
Feb 16 2018
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.
,
Feb 19 2018
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.
,
Feb 19 2018
,
Feb 20 2018
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?
,
Feb 20 2018
#6: We are adding a limit in https://chromium-review.googlesource.com/c/chromium/src/+/926366
,
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
,
Feb 21 2018
,
Mar 2 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by guidou@chromium.org
, Jan 23 2018