Memory Footprint leak debugging

[Todd Schiller]

Hi Everyone,

We're investigating a memory leak where the Memory Footprint stays high, but the JavaScript Memory recovers as expected.

The Memory Footprint does not reduce when we 1) close the sidebar on the tab, or 2) close the tab. Therefore, we suspect there's either:

• A Chrome memory leak bug in the Side Panel or tab renderer process
• The memory is actually associated with our offscreen document or background worker

Given it's the Memory Footprint, our understanding is the memory is associated with a renderer process or DOM nodes. So that would rule out the background worker. 

Unfortunately, given that it's not the JS VM, we can't use the DevTools heap analysis to investigate.

According to chrome://memory-internals/ and chrome://tracing with memory-infra available, the bulk of the retained object are from malloc. However, the tracing UI gives no visibility into the content (we just see the allocators "bucket_"s)

We're not Googlers, so can't symbolize the trace

Does anyone have any ideas how we might track down:

• Which component of our extension allocated the memory (the content script vs. the side panel vs. the offscreen document)
• What kind of content the retained memory is (e.g., DOM nodes, or extension-specific data). Is there a way to snapshot/dump the contents of the heap?
• What might be retaining the memory?

Thanks,

Todd

[woxxom]

IIRC, it was reported like 20 years ago. The closed pages of an extension seem to be retained in the extension's process for a very long time, sometimes seemingly forever. It was never fixed and I see it occasionally. The extension's processes is reused by all of the pages/popups including the offscreen document. The workaround is to close all such documents periodically (so that only the service worker remains) or reload the extension.

[woxxom]

It might be useful to inspect the raw contents of the extension's memory in a tool like System Informer (has a built-in hex viewer) or Process Explorer (can create a full memory dump). To find the process id use the built-in Chrome's task manager, which can be customized to show the PID column.

[Todd Schiller]

It might be useful to inspect the raw contents of the extension's memory in a tool like System Informer (has a built-in hex viewer) or Process Explorer (can create a full memory dump). To find the process id use the built-in Chrome's task manager, which can be customized to show the PID column

Thanks for the tip! Will give those two tools a try

 The extension's processes is reused by all of the pages/popups including the offscreen document. The workaround is to close all such documents periodically (so that only the service worker remains) or reload the extension.

We didn't see closing the offscreen document manually via chrome.offscreen.closeDocument help in cleaning up the memory footprint. If it indeed ends up being a Chrome bug, I'd like to see the Chrome team prioritize (given that part of the motivation of them migrating MV2 to MV3 was to improve resource utilization).

 

 

[Eduardo Fungairino]

We took a look at analyzing our extension process using system informer, and were able to create a dump of the memory, but we were not able to discern anything very useful. Most of the memory is being reported under `chrome.dll` and we can't really analyze it without being able to symbolize the memory dump.

For reference, I attached some screenshots. 

In order,

- Bad memory state (high overall memory consumed by the extension, but low V8 JS memory is reported)

- System informer view reports that most of the memory is being used by `chrome.dll`. Am able to view it in hex viewer, but not very enlightening)

If it makes sense, we could share a dump of the memory state after we ensure that it does not contain any customer information, and perhaps a googler could be able to tell us what's going on.

[woxxom]

>  most of the memory is being used by `chrome.dll

Yeah, it's not a problem, look inside the unnamed entries.

[Todd Schiller]

Thanks we're giving it a try

Oliver/Chrome Team, when the users closes the last extension side panel, does Chrome keep renderer objects in memory so that it opens more quickly the next time? If so, how might we determine if the memory footprint it attributable to Chrome keeping the renderer around vs. a potential memory leak in our extension?

Regards,

Todd

[Todd Schiller]

I opened a Chromium bug here: https://issues.chromium.org/issues/411868841

It looks like Chrome retains the renderer memory, and closing all tabs/the offscreen document does not have an effect