v8::Extensions memory leak
Reported by
dawid.ch...@gmail.com,
Nov 16 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Steps to reproduce the problem: Destructor of v8::Extension added using RenderThread::RegisterExtension(v8::Extension* extension) like: RenderThread::Get()->RegisterExtension(new v8::Extension()); is never called. Example in existing code: https://cs.chromium.org/chromium/src/chrome/renderer/chrome_content_renderer_client.cc?rcl=1475047097&l=370 What is the expected behavior? Destroy extensions with RenderThread. What went wrong? Memory leak. Did this work before? No Chrome version: 56.0.2920.0 (Developer Build) (64-bit) Channel: n/a OS Version: Ubuntu 16.04 Flash Version:
,
Nov 22 2016
,
Oct 11 2017
BUMP
,
Jan 22 2018
That isn't how the RenderThread is designed for RegisterExtension. The callee ensures the lifecycle for the extension passed in.
,
Feb 8 2018
,
May 9 2018
Thanks for the answer, but I still can see some extensions in chromium that are not deleted: src/chrome/renderer/benchmarking_extension.cc src/chrome/renderer/loadtimes_extension_bindings.cc src/chrome/renderer/net_benchmarking_extension.cc Those are hidden under wrapper, where ony public static Get method is exposed that creates new object. Output from this method is simply passed to RegisterExtension so there is a memory leak there (small but still...): https://cs.chromium.org/chromium/src/chrome/renderer/chrome_content_renderer_client.cc?rcl=b7a0746e11f4b9d4aa6546dc14cb56b687fe968d&l=456 That is why I thought RenderThread should be designed to delete them. |
||||
►
Sign in to add a comment |
||||
Comment 1 by manoranj...@chromium.org
, Nov 16 2016