I am not the right owner for this. Since this only manifests on one device and the relevant CRD code has not changed in years it's more likely a bug/leak in the APIs we use.

->lethalantidote who's working on SurfaceLayer-based video, I believe?

Does this need to RBB if it needs a configuration step?

As per comment #1, this doesn't require that SurfaceLayer video be enabled; I'm running dev-channel with completely default settings right now and still seeing the issue.

The issue only seems to repro on the Teemo device, FWIW, not on Kevin nor Bob.

->posciak for ChromeOS-specific video things

Comparing Task Manager to chrome:tracing w/ memory-infra enabled, I see:

Task Manager
- GPU: RAM 230MB, GPU 884MB
- CRD: RAM 64MB, GPU 535MB

chrome:tracing
- GPU: Private footprint 215MB, gpu 129MB, malloc 208MB
- CRD: Private footprint 62MB, cc 212MB, gpu N/A, malloc 10MB, v8 9MB

There seems to be a pretty huge discrepancy between the GPU memory reported by tracing and by Task Manager for the GPU process, and the "gpu" column in tracing bears no relation whatsoever to the values I see for tabs in Task Manager, FWIW, even if you e.g. combine "cc" and "gpu" columns.

I suspect pepper and video decode are not instrumented for memory-infra, that could be part of the discrepancy.

Using chrome://tracing, it seems that this is related to the "cc" memory usage - if I perform the minimize/restore cycle and take memory-infra traces before and after then I see a 20MB "cc" memory jump each time.

Also confirmed that the issue still repros on this device even if hardware video decode is disabled via about:flags.

So it seems that "cc" is accumulating texture memory in the renderer, though not strictly leaking it (CRD windows share a single renderer, and closing one window will free any memory that window has leaked), on each minimize/resume. There's still ~10-15MB of memory unaccounted for, as compared to the GPU-memory increase, though.

I can reproduce this issue on Soraka 65.0.3294.0 (platform 10214.0.0) and Eve 65.0.3294.0 (platform 10214.0.0).
Cannot reproduce on Eve 63.0.3239.48 (platform 10032.36.0).

Bisecting on Eve shows it's a regression between R65.0.3287.0 (platform 10210.0.0) and R65.0.3293.0 (platform 10211.0.0).

wez@, are you able to attach the memory-infra traces you've taken? This will help narrow things down.

The GPU process' GPU category in tracing should count all GL textures, regardless of where they come from. But video may do other things, so it's possible we are missing some video instrumentation and that may explain the issue.

Re #17: I can grab new traces easily enough. Do you need detailed memory-infra, i.e. with OOP heap-profiler enabled?

My chromebox just updated to 65.0.3319.0, and I'm no longer able to repro this leak on minimize/restore. However, the device did more or less wipe its state during the update, due to a different bug, so I can't be 100% sure this isn't due to it now being in some different experiment group.

Interesting, thanks for the update. If you see this again, I just need standard memory infra (no need for detailed). I'll try to grab an Intel Chromebook (seems to not happen on Arm, from earlier comments) and repro.

vovoy@, can you still repro? If so, can you take a trace before/after the leak? For the trace, please select "manually select categories" > "memory-infra". All other categories can be ignored. Thanks for the help!

I tested on Eve 65.0.3319.0 (platform 10302.0.0) and there is no memory leak with the repro steps.

Given that neither original user who was able to reproduce can repro, closing this out as wont-fix. Please re-open if this appears again.