Potential memory leak within GPU process |
||||||
Issue descriptionWe recently deploy the OOP HP memory profiler and we are getting back multiple reports with potential memory leaks from the GPU process. We are currently getting them from Windows users. The current threshold to get back a slow report from the GPU process is 400M private memory. see: https://cs.chromium.org/chromium/src/chrome/browser/profiling_host/background_profiling_triggers.cc?sq=package:chromium&dr=CSs&l=26 We attached a JSON files containing the potential leak allocation sites.
,
Sep 25 2017
Looking through the JSON file...it looks like most of the live objects are in MemoryProgramCache. There's probably ~1-2k programs being cached. Is that a reasonable number? If so, we should just close this bug.
,
Sep 25 2017
But, if this is the case, we will need to adjust the threshold to lower down the amount of reports we are getting.
,
Sep 25 2017
To better understand this effort - what threshold / heuristics are used to identify an allocation that may be leaky? Looking at most of the stacks, these seem to largely be things which are being cached, and which would be evicted if enough new data came in to replace them. Additionally, the leaky stacks only account for ~9.5MB total memory, and seem unlikely to be what pushes us over 400MB. I wonder if other things not captured by the memory profiler are leaking? (non-chrome Malloc, non shared memory mapped files, something else?) Also, are we seeing a new regression here? Or is just trying to track down existing / long-standing leaks?
,
Sep 25 2017
The threshold to generate a GPU process slow-reports is 400MB of private memory. The uploaded trace contains allocated objects by stackframe, but allocation sites with less than 1024 instances and below 16K are pruned and not reported. The script generating the JSON (diff) is not reporting any count below 1000. > Also, are we seeing a new regression here? We recently changed the threshold from 1G to 400M and are receiving more reports.
,
Sep 25 2017
Re #2 - seems high in terms of # of programs - let me take a look.
,
Sep 25 2017
FYI, we are having many more reports if this can help you figure out if this is an issue.
,
Sep 25 2017
We haven't stared at very many GPU heap dumps, so we don't know what the expected values are. We only shim malloc, so we're probably seeing a large discrepancy between malloc-ed memory vs mmaped memory by the GPU driver [e.g. for textures].
,
Sep 28 2017
We got an automatically uploaded heap dump from teh wild with 34,000 linked programs on macOS. Chrome version: 63.0.3223.8.
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by etienneb@chromium.org
, Sep 25 2017