Memory leaks with iframes

[Bogdan Butnaru]

I’m having a problem that looks similar to what Duong reported a couple years ago here: https://groups.google.com/d/msg/google-chrome-developer-tools/XKnjOCnJ69s/f29CSvLdUQgJ

I’m trying to develop some gadgets for Atlassian JIRA. JIRA uses gadgets based on some old web-gadget API (I think it was originally published by Google), in which each gadget is shown in an iframe on the “dashboard” page. While trying to make a script to reload the gadget iframes (to measure average times automatically) I noticed that there’s a memory leak somewhere that keeps a significant part of the old frame contents from being collected. (And, after a few dozen reloads, Chrome crashes, which led to my investigation.)

I tried to figure out what is keeping the old frames in memory, but I can’t figure it out. The “Window” objects belonging to the old frame remain (with distance “1”), but all references to them that I can see seem to be Chrome internals like “global in system / Context @....”, and nothing from the page itself.

I’ve done everything I could think of and/or find on the net, like running in an empty Chrome instance in incognito mode, and with a minimal gadget that doesn’t really contain anything except for whatever the JIRA framework adds to it, but I can’t seem to find what keeps the old frames into memory. I’m attaching a screenshot and a couple of heap dumps, hoping some Chrome wizard can read the entrails better than I.

The attached screenshot shows the bad window (the URL path for the iframe ends with gadgets/ifr), remaining on the heap even after the gadget is removed. The attached archive contains the two heap snapshots shown in the screenshot. What I did was:

1) prepared a dashboard containing a single empty gadget;

2) opened a new new Chrome window with an empty profile, and logged into the JIRA instance;

3) opened a new tab in the window, and pasted the URL to the prepared dashboard;

4) opened the console with Ctrl-Shift-J, cleared it, clicked on the Profiles tab, then recorded the first heap snapshot;

5) deleted the gadget using the dashboard button and waited a few seconds;

6) recorded the second heap snapshot.

As can be seen, there is still an instance of the Window object from the gadget iframe on the heap (and probably other stuff as well). I can’t figure out what is it that still has a reference to it on the page.

I’ve tried other things, they all seem to have similar results. Deleting the iframe element directly, either via the Element Browser or via the console, instead of step 5, causes pretty much the same results, or at least I can’t find the difference. Reloading the gadget, either via right-click or by triggering a reload from the console (e.g., window[0].location.reload()) leaves one old “window” object on the heap for each reload, they just seem accumulate and never go away as long as the top window doesn’t navigate away.

[Alexei Filippov]

Hi Bogdan,

I can see on the Containment view of your heap snapshot that the Window object is indeed held through Native Context by a global handle (155) from the Chrome native code. See the attached screenshot. So there's a native object that keeps the Window alive.

Btw, could you make and share a snippet that reproduces the issue? That'd help.

Kentaro, do you know why it is being held?

Cheers,

Alexei

​

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/c36382c1-008d-432f-8312-2c2f1fa21285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bogdan Butnaru]

Hi Alexei,

Thanks for taking a look. Answers below:

On Tuesday, April 21, 2015 at 5:11:03 PM UTC+2, Alexei Filippov wrote:

I can see on the Containment view of your heap snapshot that the Window object is indeed held through Native Context by a global handle (155) from the Chrome native code. See the attached screenshot. So there's a native object that keeps the Window alive.

Is there any reasonably way to figure out what that handle is, or when it was added, or by whom? Compiling Chrome from source and running it under a debugger would probably take more time than I can justify to my employer, but if there are some debugging APIs that I can access via a JS script or extension I could try digging deeper.

 

Btw, could you make and share a snippet that reproduces the issue? That'd help.

I’ve tried doing reproducing this with a very simple iframe inside an otherwise empty page, and it doesn’t happen there. So there’s something on the JIRA page that causes it, but I can’t figure out a way of constructing a minimal example: The dashboard page in Atlassian JIRA loads something on the order of 10MB of scripts, and the gadget iframes it hosts also automatically includes a fair bit of obfuscated JS that one can’t really control via normal means.

It does happen with any gadget I’ve tried, including a completely empty (other than what JIRA adds by default) gadget I made just for testing this. So I guess the best I can do for a minimal example is “download JIRA (and/or the Atlassian SDK), run it, and try reloading a gadget on any dashboard”. So it’s relatively easy to reproduce, but isolating the culprit is beyond me, unless there’s some technique I don’t know for doing that.

[sixin li]

Hi Bogdan,

I am experiencing a very similar problem currently. I am wondering if you have found a workaround for this issue, and if so, what did you do to fix the leaks?

Thanks,

Sixin

[Sathish kumar]

I'm experiencing a similar issue with iframes. The script tags loaded inside the iframes are not being released from the memory. we use iframes to display ads in our product. Any solution to this problem? I'm using the latest build Version 65.0.3325.181 (Official Build) (64-bit)