Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 36142 manipulating img src via javascript will generate a massive memory leak
Starred by 228 users Reported by shadowen...@gmail.com, Feb 18 2010 Back to list

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Owner: scot...@chromium.org
Closed: Aug 2011
Cc: jeremy@chromium.org, ager@chromium.org, antonm@chromium.org, mihaip@chromium.org, bolms@chromium.org, gregsimon@chromium.org, cdn@chromium.org, erikkay@chromium.org, jam...@chromium.org, tha...@chromium.org, vrk@chromium.org, gundl...@gmail.com
Components:
OS: All
Pri: 1
Type: Bug

Blocking:
issue 76571

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
Google Chrome	5.0.307.9 (Official Build 39052) beta
WebKit	532.9
V8	2.0.6.6
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.9 
(KHTML, like Gecko) Chrome/5.0.307.9 Safari/532.9


What steps will reproduce the problem?
1.  load the following html
<html>
<head>
<script type='text/javascript' src='jslib/prototype.js'> </script>
</head>
<body>
<img src="lib/showimage.php?current&camera=1" id="img">

<script type='text/javascript'> 
    function loadImage() {
        $("img").src="lib/showimage.php?
current&camera="+1+"&rand="+Math.random();
    }

    setInterval(loadImage,1000);
</script>
</body>
</html>


2.  Watch the memory consumption of the browser increase every 1 second.
3.

What is the expected result?
I would expect that the memory consumption of the task (according to the 
task manager, and system resource usage) remains relatively constant.

What happens instead?
Every cycle the amount of memory consumed is increased, as if it never 
garbage collects, nor actually frees, or reuses the memory allocated to the 
image.    The processor utilsation is around 5% so there should be no 
reason for the browser not to garbage collect.



Please provide any additional information below. Attach a screenshot if
possible.

HTML code is as folllows
<html>
<head>
<script type='text/javascript' src='jslib/prototype.js'> </script>
</head>
<body>
<iframe id="test" width="300" height="300"> </iframe>
<img src="lib/showimage.php?current&camera=1" id="img">

<script type='text/javascript'> 
    function loadImage() {
        $("img").src="lib/showimage.php?
current&camera="+1+"&rand="+Math.random();
        //window.frames['test'].location = 'http://onecam-
web/lib/showimage.php?current&camera=1&rand='+Math.random();
    }

    setInterval(loadImage,1000);
</script>
</body>
</html>

the lib/showimage.php?current&camera=1&rand=0.234532523 returns a new image 
for each call, which is the current view from a web camera.

There really should be no reason for this simple code to cause any kind of 
memory leak, however, the browser will use all of the system memory if left 
to run for a few hours. 

 
I have this problem in an application I'm writing too which frequently refreshes a 
large number of images using a similar technique.  The memory keeps increasing until 
the page breaks with an "Aw, Snap!".

FWIW I've used the heap snapshot tool to take a snapshot just after page load then 
after 30 minutes.  The snapshot shows no increase in HTMLImageElement count or size.  
The memory use as reported by the task manager shows an increase in over 200Mb 
however.

I believe I have tried destroying the image element and creating a new one and that 
has the same effect.  I'll try that again to see if that is still the case.

I'm currently on build 46793, but I've tried Chrome stable, dev and beta channels and 
they all exhibit the same issue.
Labels: Memory OS-Linux FeedbackRequested
Do you see this on Windows / Mac? Can you see if Safari has the same problem?
This is on Windows (chrome stable and build 46793), linux (build 46793).  I don't have 
access to Mac.

I've just tested on Safari on Windows (4.03) and the problem also exists there.  It 
gobbled up 500Mb RAM pretty quickly.  I've also tried to reduce the frequency of the 
image load to see if garbage collection is just slow but it appears to be increasing 
at the expected rate.
Labels: -Area-Undefined -OS-Linux -FeedbackRequested Area-WebKit OS-All
Sounds like a webkit issue then.
Comment 5 by karen@chromium.org, May 17 2010
Labels: Mstone-6
Status: Untriaged
putting this on 6 just cause it's a large memory leak. if you want, move it to x.
Comment 6 by karen@chromium.org, Jun 1 2010
Bouncing back to dglazkov - this bug isn't Mac specific, would be happy to take a look if no-one has the 
bandwidth but seems like something we should look at sooner rather than later.
That's the same test as the one I built for https://bugs.webkit.org/show_bug.cgi?id=22747.
Jeremy and others: I can run test cases like these on my local machine, with a local
web server, so no bandwidth problems here.
@Marcel.K: Folks at Google frequently use the term bandwidth alternatively as basically 
the availability of free time to do something at a specific point in time.
This issue was causing huge memory leaks in the StumbleUpon extension which used img elements with data urls.  Some key features had to be disabled.
Comment 13 by levin@chromium.org, Jun 22 2010
Status: Assigned
I'll try to find time to look into this.
I've set up an easy to use test case here:

http://waldheinz.de/2010/06/webkit-leaks-data-uris/

Please let me know if anything is wrong with it.
Comment 15 by levin@chromium.org, Jun 30 2010
Labels: -Mstone-6 Mstone-7
At the moment it doesn't appear that I'll be able to investigate and fix this in time for m6 but I should be able to do so in M7 due to other obligations.

This will be the top of items for me to look into as soon as I'm done with my current item.
Comment 16 by levin@chromium.org, Aug 19 2010
Labels: -Mstone-7 Mstone-8
Still no time at the moment.
Comment 17 by donco...@gmail.com, Aug 19 2010
I wonder if there isn't someone else who could work on this.  It's a really bad bug, it's hard to imagine several milestones worth of bugs that were more serious.
Comment 18 by darin@chromium.org, Aug 19 2010
Also running into this issue for my internal project.

IE 7,8,9 run happily in the same code path.

Safari (Mac/IPAD/PC), Chrome (PC/MAC) all keep steadily climbing in memory.

I've tried .src = null, .src = <insert static small image here>, etc with no success.

I am double buffering into 2 divs (fore and back) and popping the visibility of the div when onload fires for the image.

It is likely a webkit issue, but is a serious impediment to adopting chrome for our web application.

Please fix this one...

-bbt
Similar issue reported on Stackoverflow for Ipad on safari... (so likely webkit)

http://stackoverflow.com/questions/2986039/ipad-iphone-browser-crashing-when-loading-images-in-javascript
The problem looks to be the same as this webkit bug:  https://bugs.webkit.org/show_bug.cgi?id=23372


Hangs up my JavaScript GameBoy Color emulator when BMP method (in the settings menu inside the emu's menu bar) is switched on.
http://grantgalitz.org/gameboy/
Comment 24 by nob...@gmail.com, Oct 11 2010
This bug is preventing deployment of our application, too.

We're doing realtime control of robotic manipulators with Chromium.  We rely on changing the image src attribute via Javascript for, among other things, serializing large quantities of 3D point cloud data.

Currently our application leaks memory at ~5 MB/s because of this.
I think I saw a bug about this on the webkit tracker, but can't find it right now. Mr R, do you happen to know it?
Comment 26 by donco...@gmail.com, Oct 11 2010
The webkit link is above in comment 21 (https://bugs.webkit.org/show_bug.cgi?id=23372)

Comment 27 by thakis@google.com, Oct 11 2010
I thought I saw a different one which had some analysis and (failed) patch attempts. But maybe I'm confusing things.
Comment 28 by nob...@gmail.com, Oct 11 2010
This is likely the same issue: https://bugs.webkit.org/show_bug.cgi?id=31253
The JS GBC emulator definitely causes over a gig of memory leakage in chrome 6 & 7 when the BMP method is ticked on.
http://grantgalitz.org/gameboy/js/other/BMPCanvas.js is used when the BMP method in the GBC emu is used. Creating data URIs of BMP images dynamically through it seems to cause the sad crash icon in chrome after 10 minutes or so.
Labels: Crash
Issue 54594 has been merged into this issue.
Labels: -Mstone-8 Mstone-9
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Labels: -mstone-9 Mstone-10
Given our current velocity, we need to punt 500 bugs from m9.  Moving p2 bugs, that are not started and have an owner, to the next milestone.  If this issue absolutely needs to be fixed in the current milestone please move it back, however, at this time the focus should be on p1 bugs.
I think I have same issue with chrome not releasing memory in popup for my extension.
I causes my extension to crash after a couple days.

http://groups.google.com/a/chromium.org/group/chromium-extensions/t/bf1c8022f7ce0d33
Comment 36 by bore...@gmail.com, Dec 2 2010
I opened another issue which likely relates to this one.

http://code.google.com/p/chromium/issues/detail?id=64748

I suspect the problem is not related to IMG in concrete but to ALL tags / elements. I first recognized the problem with IFRAMES and their SRC attribute. But more testing shows that Chrome also leaks when just adding and removing plain DIVs with some text to / from the BODY.
 

I don't see a memory leak when doing this by modifying src, but I do see a big leak if I remove the node entirely and create a new one (attached).  Anyone know if these are the same issue?

(See attached.  Use a small file for quickest repro; using a larger file doesn't seem to make it leak more memory per iteration, it just makes it take longer.)

Google Maps seems to leak similarly.  maps.html attachment is a simple monkey script to scroll around; Chrome leaks badly and eventually crashes here, too.  I'd imagine it must also cause a leak with Instant updates.

maps.html
984 bytes View Download
img.html
504 bytes View Download
Comment 38 by kerz@chromium.org, Dec 9 2010
Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
This seems to be really a serious bug causing the browser to crash within minutes or seconds (depending on resources) Why is this moved from milestone 6 to 11 now? Don't you see this as critical?
This is a serious bug that caused my application to crash after 4-5 hours of normal usage. Other browsers do not exhibit the same memory leak.
Comment 41 by Deleted ...@, Jan 17 2011
This bug allows a single line of JavaScript to crash the user's computer in a matter of seconds.
yup
This is also affecting a major application we're developing at the BBC. It relies heavily on refreshing images to monitor a video server output. 
We also use a chromeless (no pun intended) chromium window running on Ubuntu, so it's not easy to restart the browser. 
We've noticed the problem on Ubuntu, XP and Win7, but Ubuntu leaks much much faster.
Comment 44 by vrk@chromium.org, Mar 9 2011
I will try to take a look at this again sometime this week!
At the risk of sounding like "me too": This is also torpedoing an application we've made that relies on painting images to a canvas. Since drawing bitmap data to a Canvas requires loading it through a DOM Image element, it is susceptible to this issue. Depending on our client's usage, their tab is going "aw snap" anytime from a few minutes to a few hours. Not acceptable for something that is supposed to be a hands-off overhead display that runs indefinitely.
Comment 46 by kareng@google.com, Mar 9 2011
Labels: -Mstone-11 MovedFrom-11 Mstone-12
rolling non releaseblocker mstone 11 bugs to mstone 12. 
Labels: -Memory bulkmove Stability-Memory
Google Chrome	5.0.307.9 (Official Build 39052) beta
WebKit	532.9
V8	2.0.6.6
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.9 
(KHTML, like Gecko) Chrome/5.0.307.9 Safari/532.9


What steps will reproduce the problem?
1.  load the following html
&lt;html&gt;
&lt;head&gt;
&lt;script type='text/javascript' src='jslib/prototype.js'&gt; &lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;img src=&quot;lib/showimage.php?current&amp;camera=1&quot; id=&quot;img&quot;&gt;

&lt;script type='text/javascript'&gt; 
    function loadImage() {
        $(&quot;img&quot;).src=&quot;lib/showimage.php?
current&amp;camera=&quot;+1+&quot;&amp;rand=&quot;+Math.random();
    }

    setInterval(loadImage,1000);
&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;


2.  Watch the memory consumption of the browser increase every 1 second.
3.

What is the expected result?
I would expect that the memory consumption of the task (according to the 
task manager, and system resource usage) remains relatively constant.

What happens instead?
Every cycle the amount of memory consumed is increased, as if it never 
garbage collects, nor actually frees, or reuses the memory allocated to the 
image.    The processor utilsation is around 5% so there should be no 
reason for the browser not to garbage collect.



Please provide any additional information below. Attach a screenshot if
possible.

HTML code is as folllows
&lt;html&gt;
&lt;head&gt;
&lt;script type='text/javascript' src='jslib/prototype.js'&gt; &lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;iframe id=&quot;test&quot; width=&quot;300&quot; height=&quot;300&quot;&gt; &lt;/iframe&gt;
&lt;img src=&quot;lib/showimage.php?current&amp;camera=1&quot; id=&quot;img&quot;&gt;

&lt;script type='text/javascript'&gt; 
    function loadImage() {
        $(&quot;img&quot;).src=&quot;lib/showimage.php?
current&amp;camera=&quot;+1+&quot;&amp;rand=&quot;+Math.random();
        //window.frames['test'].location = 'http://onecam-
web/lib/showimage.php?current&amp;camera=1&amp;rand='+Math.random();
    }

    setInterval(loadImage,1000);
&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;

the lib/showimage.php?current&amp;camera=1&amp;rand=0.234532523 returns a new image 
for each call, which is the current view from a web camera.

There really should be no reason for this simple code to cause any kind of 
memory leak, however, the browser will use all of the system memory if left 
to run for a few hours.
Labels: -Crash Stability-Crash
Google Chrome	5.0.307.9 (Official Build 39052) beta
WebKit	532.9
V8	2.0.6.6
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.9 
(KHTML, like Gecko) Chrome/5.0.307.9 Safari/532.9


What steps will reproduce the problem?
1.  load the following html
&lt;html&gt;
&lt;head&gt;
&lt;script type='text/javascript' src='jslib/prototype.js'&gt; &lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;img src=&quot;lib/showimage.php?current&amp;camera=1&quot; id=&quot;img&quot;&gt;

&lt;script type='text/javascript'&gt; 
    function loadImage() {
        $(&quot;img&quot;).src=&quot;lib/showimage.php?
current&amp;camera=&quot;+1+&quot;&amp;rand=&quot;+Math.random();
    }

    setInterval(loadImage,1000);
&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;


2.  Watch the memory consumption of the browser increase every 1 second.
3.

What is the expected result?
I would expect that the memory consumption of the task (according to the 
task manager, and system resource usage) remains relatively constant.

What happens instead?
Every cycle the amount of memory consumed is increased, as if it never 
garbage collects, nor actually frees, or reuses the memory allocated to the 
image.    The processor utilsation is around 5% so there should be no 
reason for the browser not to garbage collect.



Please provide any additional information below. Attach a screenshot if
possible.

HTML code is as folllows
&lt;html&gt;
&lt;head&gt;
&lt;script type='text/javascript' src='jslib/prototype.js'&gt; &lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;iframe id=&quot;test&quot; width=&quot;300&quot; height=&quot;300&quot;&gt; &lt;/iframe&gt;
&lt;img src=&quot;lib/showimage.php?current&amp;camera=1&quot; id=&quot;img&quot;&gt;

&lt;script type='text/javascript'&gt; 
    function loadImage() {
        $(&quot;img&quot;).src=&quot;lib/showimage.php?
current&amp;camera=&quot;+1+&quot;&amp;rand=&quot;+Math.random();
        //window.frames['test'].location = 'http://onecam-
web/lib/showimage.php?current&amp;camera=1&amp;rand='+Math.random();
    }

    setInterval(loadImage,1000);
&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;

the lib/showimage.php?current&amp;camera=1&amp;rand=0.234532523 returns a new image 
for each call, which is the current view from a web camera.

There really should be no reason for this simple code to cause any kind of 
memory leak, however, the browser will use all of the system memory if left 
to run for a few hours.
Comment 49 by vrk@chromium.org, Mar 30 2011
I've looked into this! I *think* I know what is causing the memory leak, but I need help.

First off, I am using this to test:
http://waldheinz.de/2010/06/webkit-leaks-data-uris/

The leak is happening right here:
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Element.cpp#L699
i.e. when I comment out that line, no mem leak (but the images don't get updated either, obviously)

So what's happening with old->setValue(value)? "value" is an AtomicString, which has a String, which has a StringImpl, which is ref counted.

When Attribute's m_value gets replaced, the ref counted StringImpl gets deleted. StringImpl will only delete its data if the bufferOwnership == BufferOwned:
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/text/StringImpl.cpp#L58

However, when you manipulate the img element's source and do old->setValue, at this point the old value's StringImpl's bufferOwnership == BufferInternal, so m_data is *not* released. That'd be okay so long as we're releasing m_data somewhere else. But it doesn't look like we're doing that.

Now the question is, how are we creating new StringImpls? We are using the following:
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/text/StringImpl.cpp#L104

Here is how I am reading this code (I might be wrong): 
- call createUninitialized
- This will do some clever malloc'ing and ptr manips so that we don't have to malloc twice for m_data and StringImpl
- However, this is creating a StringImpl with BufferOwnership == BufferInternal, not BufferOwned, which means it does not delete data upon destruction.... hence a memory leak!

So in attempt to fix this, I commented out the clever new StringImpl+data allocation and put in the straight-forward implementation (patch attached).

When I reran with the debugger, I saw that with my patch, now StringImpl was of BufferOwned type and it would call fastFree on the data.

Unfortunately, looking at top still shows a steadily climbing % mem usage :)

Can anyone see what I'm doing wrong, know anything about mem management in WebKit, or know of anyone I can debug this with?
mem-leak-attempted-fix.patch
1.0 KB View Download
Comment 50 by phistuck@gmail.com, Mar 30 2011
This actually seems (to me) like a quite problematic issue.

On one hand, you want the browser to keep these images on cache\memory, so when you use them again (for a hover effect, for example, without using sprites), the browser will not have to load (like var img = new Image(); img.src = "some_url" does).

On the other hand, these images should be candidates for some kind of garbage collection when the memory usage grows (a lot).
Comment 51 by fid...@gmail.com, Apr 3 2011
We encountered this memory leak in our product just before release. This problem is so severe that it means "no-go" for the product. I can't emphasize enough how crucial this is for us!

Some observations that might be useful:
1. Memory consumption increases significantly even when not using embedded images (i.e. without 'base64' tag followed by a long string). The amount of memory leaked in each image request is much higher than the size of the URI.

2. We noticed that if an image response arrives with "no-store" tag the memory of chrome process increases by the size of the image. This memory is never released until the process ends. If "no-store" is not present and cached images are saved to disk, the problem disappears.
Due to security issues, we can't leave traces of images on disk. Therefore this problem is very crucial and means we can't use Chrome for out product.

--> If there is a workaround at least for #2, please let me know!



Note not everyone wants everything cached, in fact there are many applications where you go to great lengths to avoid it.

As for a work around - simply embed your image in an Iframe and periodically replace the entire iframe.  This is a dirty workaround but works. The down side is that frames aren't rendered the same way and are harder to style. But that is how I've solved it while waiting for a patch. 

That particular work around seems to work in all browsers that has the problem including
  IE where I first found it. 
Since this bug is also present at other browser families, I just wanted to update you:

I submitted the same bug to the MS IE 9 Feedback program  in 10/06 and yesterday got this message. It works for the test at
http://waldheinz.de/2010/06/webkit-leaks-data-uris/ 

 
Product/Technology – Internet Explorer Feedback Program
 Feedback ID – 570846
 Feedback Title – memory leak: javascript image src data updates not freed from memory
 
The following fields or values changed:
 Field Status changed from [Active] to [Resolved]
 Field Resolution changed from [None] to [Fixed]
 
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=570846 (requires sign-in)


Comment 54 by k...@google.com, Apr 25 2011
Labels: Mstone13 MovedFrom12
Moving out of M12.
Comment 55 by k...@google.com, Apr 25 2011
Labels: -Mstone-12 Mstone-13
Moving out of M12.
Can someone from chromium comment on what milestone 13 means in calendar terms? We get asked by customers when this is going to be fixed all the time, and it's miserable saying: "Well, we're waiting on a 3rd party to fix something..."
Comment 57 by phistuck@gmail.com, Apr 29 2011
Chrome 11 was just released and Google releases a major stable version every six weeks, so Chrome 13 should come in 12 weeks.
However, since this is not fixed, but only "Assigned" and it has been this way for 10 months, this is hardly a guarantee of any sort.
Keep saying what you mentioned, there is no better answer right now.
And keep in mind that this not only causes chrome to leak like a waterfall, but hangs it upon shutdown in Mac os x for doing the WAV PCM audio variant of this. 
Comment 59 by fid...@gmail.com, May 4 2011
We found that images arriving with "Cache-Control: no-store" in their header leak much heavily than "regular" images.  For example 512x512 color jpeg compressed to just 22KB will cause a leak of ~20-40KB, but if "no-store" tag is used then the leak is 1MB per image(!) (the size of the uncompressed image).
I believe this is a different bug than the current one (#36142) so I opened a new bug report for it, demo URL is included:  http://code.google.com/p/chromium/issues/detail?id=81517

Despite the difference between the bugs, it might be relevant for whoever tries to fix this current bug (If there such a person...) - Therefore, I'm commenting about it here. 

Comment 60 by fed...@gmail.com, May 17 2011
This bug affects our development to such an extent that we'll probably have to remove chrome/safari from our list of supported browsers :(

I wrote a simple test case, using html5 canvas to generate data URIs, and then load those URIs into an Image via it's src attribute. Right now the code re-uses the same instance of Image, but the results are identical even if you create new Image for every new URI.

http://pages.cpsc.ucalgary.ca/~federl/chromeMemLeak.html

On my machine this test case uses up memory at around 1 gigabyte per 9 seconds!!!

Cc: gregsimon@chromium.org
Comment 62 by djac...@gmail.com, May 17 2011
when I run the test (http://pages.cpsc.ucalgary.ca/~federl/chromeMemLeak.html) and wait for 1000 to inspect the page, I got a tab crash when I click on Resources.
when it's opened from the start, there is a huge memory consumption (almost equal to the tab) due to (I suspect) the name of each images in the tab Resources/Frames/Images, because they are displayed with the full data (in base 64), maybe it's the cause of the tab crash but the dev tools are in an other process (and thread).
Comment 63 by fi...@mxd.cz, May 17 2011
confirmed massive memory leak - Chromium 13.0.768.0 (Developer Build 85577 Linux) Ubuntu 10.04
Cc: vrk@chromium.org
Owner: jam...@chromium.org
Stealing this bug - let me know if you were actually working on it, Victoria!

From looking at a memory profile it seems that we're leaking the URL string itself, not the encoded or decoded image data.

http://webstuff.nfshost.com/innerhtmlimg.html loads 50 randomly generated 500x500 images.  I've confirmed that we do free up the <img> element and the associated pixel data, so it's just the strings.

The memory growth on my box is ~400mb
500x500x4 bytes/pixel = 1000kb/image
base64 encoding -> 1333kb/image
strings in WebCore are utf-16, so double that to 2666kb/image
50 loads = 133mb

so we're leaking the URL string itself 3 times per load.

one leak is in CachedResourceLoader::m_validatedURLs, which is a HashSet<String>.  now to find the other two....
Jamesr: same thing happens with wav PCM data uri strings. Leaks with <audio> as well, not just <IMG>
I've been working on a web app in which the FileAPI is used to convert
a images that will be uploaded to a base64 datauri. As I need to
inspect the original image size I put the resulting base64 in a IMG's
element src either in memory o in the DOM.

I've tested a few scenarios on a 4gb MacBook Pro running Mac OS X
10.6, Chrome 10 and Chromium 13. The FileAPI load and convert to
datauri work fine but as soon as I change the image src I've
experienced ~1.2gb memory leaks with up to 1mb images. After the form
is submitted the browser cleans up memory usage just fine.

With 1-1.5mb images the browser completes the submit but doesn't
manage to cleanup and freezes the whole process afterwards (including
tabs that were originated from the original one).

When testing with images bigger than 1.5mb the tab crashes as memory
consumption jumps immediately from 80mb to 1.8gb.


On 17/05/2011, at 20:45, "chromium@googlecode.com"
<chromium@googlecode.com> wrote:
This bug is not limited to data: URIs.  Place the attached HTML and PNG files in the same directory, load leak.html, and watch memory usage skyrocket.  If you are sensitive to flashing images, then replace leak2.png with a copy of leak.png (the only reason for having two images is to visually demonstrate that the image loading process is working).  The images are large to ensure memory usage grows quickly.

The attached screenshot.png shows the tab at almost 5GB of usage after only a short time open.

I'm running Chrome 13.0.767.1 (Official Build 85531) on Ubuntu 11.04.
leak.html
1.4 KB View Download
leak2.png
738 KB View Download
leak.png
754 KB View Download
screenshot.png
573 KB View Download
I think we've "me-too"'d this bug report a little much.
Comment 70 by phistuck@gmail.com, May 18 2011
When I opened http://pages.cpsc.ucalgary.ca/~federl/chromeMemLeak.html in a new incognito window and activated the Chrome task manager, I saw the memory growing beyond 1.5 GB in two minutes - and then my hard drive started 'working' massively and my whole system froze every few seconds (and when it was not frozen, it was simple not responding to my mouse clicks).

I had to wait about half an hour or more until I could get my computer to close that incognito window/make it (specifically) hang so it would let the rest of the system be responsive.

What I am getting at here, is that Chrome did not kill the tab by itself, even though it was using (way) too much memory. There was no out of memory kill or anything.
I believe Chrome is supposed to protect the users against those cases.
Am I wrong?

If I am not wrong, should I create a new issue for this, or is this covered in this issue as well?
Comment 71 by phistuck@gmail.com, May 18 2011
Forgot to mention -
It happened on Windows Vista Home Premium SP 2 (Classic Windows theme), with Chrome 13.0.767.1 canary.
I agree with grant we've "mee-too"'d this enough.

James: It is great news you can do some progress with this issue. Even if you do not fix it 100% it is still a progress. If you take down memory leak by 50% it means my application can run twice as long before crashing.

You gave me a hope of resurrecting my project. Many thanks.
Comment 73 by fid...@gmail.com, May 19 2011
Comment #70 seems to be related to bug #81517 (http://code.google.com/p/chromium/issues/detail?id=81517).
The leak there is HUGE because the *decompressed* image is not released. 
For example a 20KB image can easily grab 1MB of memory and never let it go... (See the above bug for details and demo).
Cc: cdn@chromium.org
Issue 81517 has been merged into this issue.
Cc: mihaip@chromium.org
Issue 25047 has been merged into this issue.
Labels: -Mstone-13 Mstone-14 MovedFrom13
Moving !type=meta|regression and !releaseblocker to next mstone
Labels: -MovedFrom12 MovedFrom-12
Cc: ager@chromium.org gundl...@gmail.com erikkay@chromium.org bolms@chromium.org antonm@chromium.org
Issue 76571 has been merged into this issue.
Comment 79 Deleted
Blocking: 76571
Labels: -Pri-2 Pri-1
Any update on this?

Raising the priority since this was identified as a reason for high memory usage with adblock, which is a P1 issue.

Thanks.
Owner: gregsimon@chromium.org
This probably needs another owner - I have a few patches pending webkit review that fix the issue, but they will need some work to drive to completion.  Assigning to greg to find an owner..
I am also suffering from this bug, sad to see it has been reported 1,5 years ago and is still not fixed.

We use data-URIs as workarround, which don't seem to trigger the memory leak but unfourtunatly have higher bandwith and processing overhead.
Use blob uris via createObjectUrl to get around the data-uri issue. There are some minor issues with blob uris while debugging from the local file system, as documented in issue 64547.
Two patches pending for WebKit that fix the testcases I could find for this behaviour: https://bugs.webkit.org/show_bug.cgi?id=61006 and https://bugs.webkit.org/show_bug.cgi?id=61894
Comment 86 by kareng@google.com, Jul 19 2011
Issue 89548 has been merged into this issue.
Comment 87 by ise...@gmail.com, Jul 19 2011
The best alternative without changing any server-side code is to XHR any images with responseType = "arraybuffer" (or "blob" once the relevant issue for that is fixed), then append xhr.response to a new WebKitBlobBuilder and generate a blob via blobbuilder.getBlob(xhr.contentType). Finally create an object URL with webkitURL.createObjectURL(blob) and once you're done with the image (e.g. on unload), webkitURL.revokeObjectURL(url).
well, not so great - requires a whole lot of brand new stuff (XHR2, ArrayBuffer) and webkit specific stuff like WebKitBlobBuilder and revokeURL.
BlobBuilder and object URLs are in Mozilla and have been accepted by Microsoft. This is the appropriate way to handle the situation in the long term.
Comment 90 by ise...@gmail.com, Jul 19 2011
How is that a problem? 99% of your Chrome visitors are running either Chrome 11 or 12, which both support it. It's not like you'd use this workaround for browsers that don't suffer from issue 36142. Also, it's not WebKit-specific. Those are standard interfaces from the W3C File API, just vendor prefixed.
> This is the appropriate way to handle the situation in the long term.
I don't see how setting the src-attribute is any worse, except that its broken in webkit ;)

> just vendor prefixed.
exactly, the usual if(...) code stuff. hopefully the api will be non-prefixed soon.
Owner: scot...@chromium.org
This code doesn't have any effect:
  img.src = null;

Is this bug related?
Status: Fixed
https://bugs.webkit.org/show_bug.cgi?id=61006 and https://bugs.webkit.org/show_bug.cgi?id=61894 have been landed in WebKit.

I'm going to mark this as fixed (should hit 14), as the tests linked above work properly now with those patches applied. If there are similar/related problems, we should probably start a new, more concise bug rather than piling on to this one. 
Status: Assigned
Reopening, unfortunately. Had to rollback one of the fixes in webkit.
Status: Fixed
Fix merged to M14.
Issue 48063 has been merged into this issue.
Blocking: 107408
Blocking: -107408
Project Member Comment 100 by bugdroid1@chromium.org, Oct 13 2012
Blocking: -chromium:76571 chromium:76571
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 101 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -Stability-Memory -Mstone-14 Cr-Content Performance-Memory M-14
Project Member Comment 102 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 103 by bugdroid1@chromium.org, Apr 1 2013
Labels: -Performance-Memory Stability-Memory
Project Member Comment 104 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Labels: hasTestcase
Sign in to add a comment