My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 36142: manipulating img src via javascript will generate a massive memory leak
224 people starred this issue.
Comments by non-members will not trigger notification emails to users who starred this issue.
Back to list
 
Reported by Shadowen...@gmail.com, Feb 18, 2010
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. 

May 11, 2010
#1 SeanlGar...@gmail.com
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.
May 11, 2010
#2 thestig@chromium.org
Do you see this on Windows / Mac? Can you see if Safari has the same problem?
Labels: Memory OS-Linux FeedbackRequested
May 12, 2010
#3 SeanlGar...@gmail.com
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.
May 12, 2010
#4 thestig@chromium.org
Sounds like a webkit issue then.
Cc: dglaz...@chromium.org
Labels: -Area-Undefined -OS-Linux -FeedbackRequested Area-WebKit OS-All
May 17, 2010
#5 ka...@chromium.org
putting this on 6 just cause it's a large memory leak. if you want, move it to x.
Status: Untriaged
Owner: dglaz...@chromium.org
Labels: Mstone-6
Jun 1, 2010
#6 ka...@chromium.org
(No comment was entered for this change.)
Owner: jer...@chromium.org
Cc: tha...@chromium.org
Jun 6, 2010
#7 jeremy@chromium.org
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.
Owner: ---
Cc: jer...@chromium.org
Jun 6, 2010
#8 dglazkov@chromium.org
(No comment was entered for this change.)
Owner: dglaz...@chromium.org
Cc: -dglaz...@chromium.org
Jun 6, 2010
#9 dglazkov@chromium.org
That's the same test as the one I built for https://bugs.webkit.org/show_bug.cgi?id=22747.
Jun 6, 2010
#10 Marcel.K...@gmail.com
Jeremy and others: I can run test cases like these on my local machine, with a local
web server, so no bandwidth problems here.
Jun 6, 2010
#11 brycesto...@gmail.com
@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.
Jun 9, 2010
#12 donco...@gmail.com
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.
Jun 22, 2010
#13 levin@chromium.org
I'll try to find time to look into this.
Status: Assigned
Owner: le...@chromium.org
Jun 23, 2010
#14 waldheinz@gmail.com
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.
Jun 30, 2010
#15 levin@chromium.org
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.
Labels: -Mstone-6 Mstone-7
Aug 18, 2010
#16 levin@chromium.org
Still no time at the moment.
Labels: -Mstone-7 Mstone-8
Aug 18, 2010
#17 donco...@gmail.com
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.
Aug 19, 2010
#18 darin@chromium.org
(No comment was entered for this change.)
Owner: v...@chromium.org
Aug 26, 2010
#19 bigbirdt...@gmail.com
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
Aug 26, 2010
#20 bigbirdt...@gmail.com
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
Sep 2, 2010
#21 donco...@gmail.com
The problem looks to be the same as this webkit bug:  https://bugs.webkit.org/show_bug.cgi?id=23372


Sep 29, 2010
#22 grantgal...@gmail.com
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/
Oct 10, 2010
#24 nobbis
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.
Oct 10, 2010
#25 thakis@chromium.org
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?
Cc: jam...@chromium.org
Oct 10, 2010
#26 donco...@gmail.com
The webkit link is above in comment 21 (https://bugs.webkit.org/show_bug.cgi?id=23372)

Oct 10, 2010
#27 thakis@google.com
I thought I saw a different one which had some analysis and (failed) patch attempts. But maybe I'm confusing things.
Oct 10, 2010
#28 nobbis
This is likely the same issue: https://bugs.webkit.org/show_bug.cgi?id=31253
Oct 10, 2010
#29 grantgal...@gmail.com
The JS GBC emulator definitely causes over a gig of memory leakage in chrome 6 & 7 when the BMP method is ticked on.
Oct 10, 2010
#30 grantgal...@gmail.com
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.
Oct 10, 2010
#31 thakis@chromium.org
(No comment was entered for this change.)
Labels: Crash
Oct 10, 2010
#32 thakis@chromium.org
 Issue 54594  has been merged into this issue.
Oct 19, 2010
#33 lafo...@chromium.org
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Labels: -Mstone-8 Mstone-9
Nov 5, 2010
#34 lafo...@chromium.org
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.
Labels: -mstone-9 Mstone-10
Dec 2, 2010
#35 marek.ch...@gmail.com
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
Dec 2, 2010
#36 Bore...@gmail.com
I opened another issue which likely relates to this one.

https://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.
 

Dec 4, 2010
#37 oldglenn...@gmail.com
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.

img.html
504 bytes   View   Download
maps.html
984 bytes   View   Download
Dec 9, 2010
#38 kerz@chromium.org
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Labels: -Mstone-10 MovedFrom-10 Mstone-11
Dec 10, 2010
#39 thomas.f...@gmail.com
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?
Dec 13, 2010
#40 ahmad.za...@gmail.com
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.
Jan 17, 2011
#41 tfi...@willowgarage.com
This bug allows a single line of JavaScript to crash the user's computer in a matter of seconds.
Jan 17, 2011
#42 grantgal...@gmail.com
yup
Mar 9, 2011
#43 geoff.ho...@gmail.com
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.
Mar 9, 2011
#44 vrk@chromium.org
I will try to take a look at this again sometime this week!
Mar 9, 2011
#45 carlrgo...@gmail.com
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.
Mar 9, 2011
#46 kar...@google.com
rolling non releaseblocker mstone 11 bugs to mstone 12. 
Labels: -Mstone-11 MovedFrom-11 Mstone-12
Mar 18, 2011
#47 lafo...@chromium.org
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


<b>What steps will reproduce the problem?</b>
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.
<b>3.</b>

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

<b>What happens instead?</b>
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.



<b>Please provide any additional information below. Attach a screenshot if</b>
<b>possible.</b>

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: -Memory bulkmove Stability-Memory
Mar 18, 2011
#48 lafo...@chromium.org
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


<b>What steps will reproduce the problem?</b>
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.
<b>3.</b>

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

<b>What happens instead?</b>
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.



<b>Please provide any additional information below. Attach a screenshot if</b>
<b>possible.</b>

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
Mar 29, 2011
#49 vrk@chromium.org
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
Mar 29, 2011
#50 phistuck
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).
Apr 3, 2011
#51 fid...@gmail.com
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!



Apr 4, 2011
#52 Shadowen...@gmail.com
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. 
Apr 19, 2011
#53 thomas.f...@gmail.com
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)


Apr 25, 2011
#54 kerz@google.com
Moving out of M12.
Labels: Mstone13 MovedFrom12
Apr 25, 2011
#55 kerz@google.com
Moving out of M12.
Labels: -Mstone-12 Mstone-13
Apr 28, 2011
#56 carlrgo...@gmail.com
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..."
Apr 29, 2011
#57 phistuck
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.
Apr 29, 2011
#58 grantgal...@gmail.com
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. 
May 4, 2011
#59 fid...@gmail.com
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:  https://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. 

May 17, 2011
#60 fed...@gmail.com
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!!!

May 17, 2011
#61 gregsimon@chromium.org
(No comment was entered for this change.)
Cc: gregsimon@chromium.org
May 17, 2011
#62 djac...@gmail.com
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).
May 17, 2011
#63 filip@mxd.cz
confirmed massive memory leak - Chromium 13.0.768.0 (Developer Build 85577 Linux) Ubuntu 10.04
May 17, 2011
#64 jamesr@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....
Owner: jamesr@chromium.org
Cc: vrk@chromium.org
May 17, 2011
#65 grantgal...@gmail.com
Jamesr: same thing happens with wav PCM data uri strings. Leaks with <audio> as well, not just <IMG>
May 17, 2011
#67 btrigue...@gmail.com
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:
May 17, 2011
#68 sts.nitr...@gmail.com
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
leak.png
754 KB   View   Download
leak2.png
738 KB   View   Download
screenshot.png
573 KB   View   Download
May 17, 2011
#69 grantgal...@gmail.com
I think we've "me-too"'d this bug report a little much.
May 17, 2011
#70 phistuck
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?
May 17, 2011
#71 phistuck
Forgot to mention -
It happened on Windows Vista Home Premium SP 2 (Classic Windows theme), with Chrome 13.0.767.1 canary.
May 18, 2011
#72 marek.ch...@gmail.com
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.
May 19, 2011
#73 fid...@gmail.com
Comment #70 seems to be related to  bug #81517  (https://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).
May 20, 2011
#74 rvargas@chromium.org
 Issue 81517  has been merged into this issue.
Cc: cdn@chromium.org
Jun 1, 2011
#75 jamesr@chromium.org
 Issue 25047  has been merged into this issue.
Cc: mihaip@chromium.org
Jun 2, 2011
#76 lafo...@chromium.org
Moving !type=meta|regression and !releaseblocker to next mstone
Labels: -Mstone-13 Mstone-14 MovedFrom13
Jun 2, 2011
#77 lafo...@chromium.org
(No comment was entered for this change.)
Labels: -MovedFrom12 MovedFrom-12
Jun 8, 2011
#78 mihaip@chromium.org
 Issue 76571  has been merged into this issue.
Cc: ant...@chromium.org erik...@chromium.org ager@chromium.org gundl...@gmail.com bolms@chromium.org
Jun 28, 2011
#80 eroman@chromium.org
(No comment was entered for this change.)
Blocking: 76571
Jun 28, 2011
#81 eroman@chromium.org
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.
Labels: -Pri-2 Pri-1
Jun 28, 2011
#82 jamesr@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..
Owner: gregsimon@chromium.org
Jul 19, 2011
#83 ceisse...@gmail.com
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.
Jul 19, 2011
#84 downch...@gmail.com
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 .
Jul 19, 2011
#85 scottmg@chromium.org
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
Jul 19, 2011
#86 kar...@google.com
 Issue 89548  has been merged into this issue.
Jul 19, 2011
#87 iSe...@gmail.com
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).
Jul 19, 2011
#88 ceisse...@gmail.com
well, not so great - requires a whole lot of brand new stuff (XHR2, ArrayBuffer) and webkit specific stuff like WebKitBlobBuilder and revokeURL.
Jul 19, 2011
#89 downch...@gmail.com
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.
Jul 19, 2011
#90 iSe...@gmail.com
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.
Jul 19, 2011
#91 ceisse...@gmail.com
> 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.
Jul 19, 2011
#92 scottmg@chromium.org
(No comment was entered for this change.)
Owner: scottmg@chromium.org
Jul 20, 2011
#93 Mayhem...@gmail.com
This code doesn't have any effect:
  img.src = null;

Is this bug related?
Jul 22, 2011
#94 scottmg@chromium.org
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: Fixed
Jul 25, 2011
#95 scottmg@chromium.org
Reopening, unfortunately. Had to rollback one of the fixes in webkit.
Status: Assigned
Aug 3, 2011
#96 scottmg@chromium.org
Fix merged to M14.
Status: Fixed
Sep 8, 2011
#97 dglazkov@chromium.org
 Issue 48063  has been merged into this issue.
Dec 19, 2011
#98 mihaip@chromium.org
(No comment was entered for this change.)
Blocking: 107408
Jan 3, 2012
#99 scot...@google.com
(No comment was entered for this change.)
Blocking: -107408
Oct 13, 2012
#100 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Blocking: -chromium:76571 chromium:76571
Mar 10, 2013
#101 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-WebKit -Stability-Memory -Mstone-14 Cr-Content Performance-Memory M-14
Mar 13, 2013
#102 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 1, 2013
#103 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Performance-Memory Stability-Memory
Apr 5, 2013
#104 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Jun 17, 2014
#105 nyerrami...@chromium.org
(No comment was entered for this change.)
Labels: hasTestcase
Sign in to add a comment

Powered by Google Project Hosting