Potential memory leak with WebMStreamParser |
||||||||
Issue descriptionI'm using the chromium ToT version, keeping tabs open for multiple days. A tab was opened on Youtube listening to Jazz music. I'm periodically taken memory dumps using memory-infra. By using a diffing tools, we can determine remaining allocated between two memory dumps with points to potential memory leak. It seems to me there is a memory leak with the stream parser. See attached stackframes.
,
Jun 15 2017
The process moved from 138M to 322M in two days.
,
Jun 15 2017
,
Jun 15 2017
Doesn't look webaudio-ish. Chromium side looks like media/formats or media/filters, Blink side looks like modules/mediasource chcunningham@chromium.org or wolenetz@chromium.org - can you help direct this to the right place?
,
Jun 15 2017
If someone needs some help on this one,... I'm still listening to music. I can also attach a debugger if needed.
,
Jun 15 2017
StreamParserBuffers are what are being allocated and managed in those ranges. We expect they can potentially grow in footprint over time (with some limits). Can you take some memory heap snapshot(s) and/or profile (https://developers.google.com/web/tools/chrome-devtools/memory-problems/heap-snapshots) to help us identify what's taking so much space over time (at least, in the renderer/tab process)?
,
Jun 15 2017
,
Jun 15 2017
JS HeapDump can be found here: https://drive.google.com/open?id=0B2eVPm4kQyHoTWNpQmRMZmZwemc
,
Jun 15 2017
Total Resident Memory : 377M
,
Jun 15 2017
Looking at one of the memory dumps shared privately, I'm not certain this is unexpected. In the MediaSource demuxer (which holds onto parsed compressed media buffers for play-out into the decoder), we allow up to 150MB per video track, and 12MB per audio track, of compressed media to be buffered by the web app. The web app itself can have copies of some/all/more than this (and can have more than 1 track of each type over time), and the media pipeline continually has a bunch of frames allocated for decode outputs (though in cases, they may not be in the same process as the renderer). In one case, I'm seeing about 140MB from "malloc" in the dump from one process (with thread id 76136 like those in the OP, above) associated with a youtube playback (total resident 270.7MB). This fits under the 150MB video track buffer limit. tl;dr: I'm not sure there's a leak in media pipeline here.
,
Jun 16 2017
,
Jun 19 2017
The renderer went OOM after waiting a few days.
,
Jun 20 2017
etienne: We need to follow up further. Could the OOM have happened because of profiling overhead? e.g. If we run w/o native heap profiling, how does memory usage on this tab change over the course of several days?
,
Jun 20 2017
OOM happened when I launched a memory dump. Which probably means the process was in a critical memory pressure and the tracing overhead just killed it. I'm running a new instances, which may take a few days, to repro again.
,
Aug 4 2017
This is coming up again in a trace. I'm adding more metrics in case it can help.
,
Aug 21 2017
The same thing happened this week-end with my browser (canary). I'll start to think that Chrome doesn't like Jazz :( See attachments. Unfortunately, I was not able to grab a trace. When the renderer is too bloated, it's quite common that tracing + memory infra failed, and crash the process.
,
Nov 29 2017
,
Aug 3
Don't think this is a leak. Closing as WontFix since MSE may accrue up to 180mb of these buffers before automatic GC kicks in. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by etienneb@chromium.org
, Jun 15 2017