All modern web-browsers except IE9 are vulnerable to a huge memory leak(code.google.com)
code.google.com
All modern web-browsers except IE9 are vulnerable to a huge memory leak
http://code.google.com/p/chromium/issues/detail?id=81517
70 comments
From personal experience I'll chime in that IE9 crashes just frequently enough for memory leaks not be a huge issue.
Zing! There was an issue with pre PHP5.3 where circular references caused memory leaks. In code that could not be moved to 5.3, long running processes were written to auto-restart at a certain point.
Good stuff. We had some issues along these lines at my last job. We were never clever enough to auto-restart though and just perodically restarted things manually and disabled opcode caching.
I prefer Chrome, but the only time I've ever seen IE9 crash is on a system that was running old Nvidia drivers. After updating the nvidia graphics drivers to the latest (at the time) the crashes went away and I haven't seen an IE9 crash since.
If you are seriously having an issue with IE9 crashing and aren't just looking for a reason to zing Microsoft, try updating your graphics drivers... Unfortunately having to worry about that sort of thing is the price you pay for the fast low-level GPU drawing/compositor operations.
If you are seriously having an issue with IE9 crashing and aren't just looking for a reason to zing Microsoft, try updating your graphics drivers... Unfortunately having to worry about that sort of thing is the price you pay for the fast low-level GPU drawing/compositor operations.
I think the browser has become quite a bit more stable since the last release but I still run into more issues with it while browsing then I generally do with firefox or opera. I work at microsoft so I'm also a little biased against ie9 after dogfooding the beta bits due to peer pressure.
Has anyone tested Opera?
I hate how Opera never gets any love. It's been the most innovative browser for years now, it had tabs before other browsers even had an MDI and was fast even on my PC with 16 MB RAM.
I was a long time Opera user and love its configurability and full keyboard support for general browsing, but the Chromium dev tools won me over from a developer perspective and I disliked switching between the two.
You should check out the new Dragonfly. Grab the Opera Next build http://www.opera.com/browser/next/ to poke around. Dragonfly has gotten a masssive upgrade in the past 6mo.
That said, the Chrome dev tools are pretty righteous, too. :)
That said, the Chrome dev tools are pretty righteous, too. :)
Nice, just installed and I'm loving the JS terminal so far. Thanks for the link.
Hmm, I always prefer Firebug for development, but development and browsing are two separate tasks, so I have no problem using both. Chrome is a solid browser too, though.
Just booted up firebug due to your comment because I hadn't used it in a while. Here is my reaction after using Chromium dev tools:
- JavaScript auto complete text doesn't display right, it is a different font size shadow that obscures the typed text.
- Pressing tab multiple times will not cycle autocomplete, but instead jump the focus out of the console and into the search prompt.
- Really minor, but I prefer a terminal where the output and input are simply in the same line rather than in seperate locations that require looking back and forth.
- If I declare a function "hello" in the terminal, and then type "hello", it merely prints "hello()" instead of printing the source of the function. Printing the source of the function with no extra work is especially valuable if I grab the non minimized version of a new javascript library and want to poke around and see what everything does.
+ I do think the "Net" tab displays requests a bit more concisely than Chromium. This could be beneficial if you are dealing with pages with lots of pictures.
= CSS and DOM inspection seems about equal.
My main concern is JavaScript though, as my current app is doing all of its rendering client side with only the Model layer on server.
- JavaScript auto complete text doesn't display right, it is a different font size shadow that obscures the typed text.
- Pressing tab multiple times will not cycle autocomplete, but instead jump the focus out of the console and into the search prompt.
- Really minor, but I prefer a terminal where the output and input are simply in the same line rather than in seperate locations that require looking back and forth.
- If I declare a function "hello" in the terminal, and then type "hello", it merely prints "hello()" instead of printing the source of the function. Printing the source of the function with no extra work is especially valuable if I grab the non minimized version of a new javascript library and want to poke around and see what everything does.
+ I do think the "Net" tab displays requests a bit more concisely than Chromium. This could be beneficial if you are dealing with pages with lots of pictures.
= CSS and DOM inspection seems about equal.
My main concern is JavaScript though, as my current app is doing all of its rendering client side with only the Model layer on server.
The console isn't as advanced in Firebug as Chromium or Safari, no doubt. I prefer the CSS and DOM inspection system, however - having to pause JS execution to look at the current state is not nearly as convenient. If you want to do that, though, Firebug offers that as well.
Hmm, I'll have to try the chrome dev tools, I didn't know they were so advanced, thank you!
I've tried using Dragonfly several times and I can never even get started with it. It's one of those programs which I simply cannot penetrate the UI. This isn't surprising when it's an app like Blender, but I'm not sure how a browser debugger could be so confusing.
I just tested, nothing happened(no leak).
I'd love to but the test site is over quota. Surprise surprise.
How does the reporter know this is a leak? High memory consumption is not a "memory leak".
The RFC says the data can be retained in history buffers as part of normal operation and as far as I can tell that's what is happening here.
The RFC says the data can be retained in history buffers as part of normal operation and as far as I can tell that's what is happening here.
It is OK to have in-memory cache for certain resources. It isn't OK when this cache doesn't shrink under memory pressure. This usually leads to swap trashing after the cache becomes bigger than the available physical RAM on the system. Swap trashing makes the system unusable in most cases. See the comment #6 http://code.google.com/p/chromium/issues/detail?id=81517#c6 .
Ah, that was added after my comment. Nevertheless, there is no evidence this is a memory leak.
It depends on how strictly you define "memory leak." I'm currently in the process of diagnosing a problem that causes steadily increasing memory consumption in one of our servers. Odds are that we are simply keeping a bunch of data around past the time when it should be detected as stale and expunged. If that's true, we still have pointers to the objects and know exactly where and what they are, so the memory has not been "leaked" by the strict definition that we are no longer able to access or deallocate it. Still, pending diagnosis, everyone refers to it as the "memory leak," technical and nontechnical people alike. Usually there is a lot of discussion of such a bug before the cause is detected and not so much afterwards, so there would not be much opportunity to use the term "memory leak" if it was only used postmortem. (Not to mention that true memory leaks are pretty rare nowadays except for those unfortunate enough to be programming in C.)
I've had Ruby processes run wild (think turning off the garbage collector) and grow to 20-30GB on my MacBook and it didn't make my system unusable. Things slowed down, but I could pretty easily open up the Activity Monitor and kill the offending process.
In the highly unlikely scenario where you actually allowed the system to allocate 30GB of swap space, this might not cause the system to become unresponsive since most of the memory in "use" would never be touched, as it comes from discarded but uncollected Ruby objects.
This is a pretty solid hypothesis, but wouldn't the same be true of the exploited cached images? They are essentially the same thing: stale resources that won't be used again, and those regions need to be free'd up.
I suspect there are two major causes for the differences: (1) the faster allocation rate in the browser prevents the system from keeping OS/GUI-critical pages in RAM, and (2) the browser is constantly checking the cache for matching images, so the pages used by the cache are being kept in RAM and/or repeatedly loaded and unloaded.
Firefox also causes not insignificant pixmap memory growth in the Xorg process (xrestop was used to verify) when running this test: https://code.google.com/p/chromium/issues/detail?id=36142#c6...
Is there a Gecko bug for this issue yet, so I can add myself to the CC list?
Is there a Gecko bug for this issue yet, so I can add myself to the CC list?
For which issue? The page in question is loading lots of different (from the browser's point of view) images. They won't be released until sometime later (in particular, for Gecko until after GC runs on the style data structures). So I would expect memory usage to grow here here until said GC happens, then drop, then grow again, etc.
While the images are live, they're stored on the X server, because that's where they need to be drawn; in many cases this will just place them directly into the graphics memory. There _are_ existing Gecko bugs on trying to reduce X server resource usage by dynamically deciding which images to store in the client and which on the server... The bugs are mostly motivated by thin client setups where the X client actually has a lot more in the way of hardware resources than the X server does. Of course those are high-latency X setups (compared to your typical desktop), which makes storing the images you really need on the server all the more important.
While the images are live, they're stored on the X server, because that's where they need to be drawn; in many cases this will just place them directly into the graphics memory. There _are_ existing Gecko bugs on trying to reduce X server resource usage by dynamically deciding which images to store in the client and which on the server... The bugs are mostly motivated by thin client setups where the X client actually has a lot more in the way of hardware resources than the X server does. Of course those are high-latency X setups (compared to your typical desktop), which makes storing the images you really need on the server all the more important.
Doesn't appear to leak in Chrome 13.0.767.1
Now, let's see which of these browsers fix this issue the fastest. My bet is that Chrome will be the first.
It looks like the first was IE9 - see http://code.google.com/p/chromium/issues/detail?id=36142#c53 .
Chrome doesn't fix the related bug for more than a year - http://code.google.com/p/chromium/issues/detail?id=36142 .
Safari wins with more than two years - https://bugs.webkit.org/show_bug.cgi?id=23372 .
Even older (dec 2008) than Webkit:
http://code.google.com/p/chromium/issues/detail?id=5688
This looks like a fairly old leak in all WebKit browsers. There's a year+ old bug about it filed against Chromium, and I think there's one against WebKit proper as well: http://code.google.com/p/chromium/issues/detail?id=36142
Frustratingly, the chromium and webkit devs seem to have been ignoring it. In my case, it made one of my products completely unusable on all webkit-based browsers... which includes Android, WebOS and iOS. Sigh.
Frustratingly, the chromium and webkit devs seem to have been ignoring it. In my case, it made one of my products completely unusable on all webkit-based browsers... which includes Android, WebOS and iOS. Sigh.
Here's the upstream WebKit bug which has some more analysis:
https://bugs.webkit.org/show_bug.cgi?id=61006
https://bugs.webkit.org/show_bug.cgi?id=61006
The bug you link here (36142) is important because demonstrations there show that memory grows unbounded even without using no-store (one demonstration uses images from the local hard drive, from whence no cache control directives could possibly be obtained, and eats through ~1.3GB/min of RAM).
Somewhat related: http://code.google.com/p/chromium/issues/detail?id=25047
(This affects all Webkit based browsers)
(This affects all Webkit based browsers)
Can't reproduce in Firefox 6 neither.
Firefox 6? Do you mean 3.6?
No. He's replying from the future.
Firefox nightly builds are currently 6.0a1.
Ahh, thanks. Do nightly build version numbers roughly correspond to release versions? That is, are the features in FF6(n) the same as those that will be in FF6(f)?
Yes, they correspond.
Currently FF Nightly is 6. That will become Aurora 6, then Beta 6, and then Firefox (final) 6. The features in all of those should be the same, except that we might fix some bugs along the way and/or disable some features if they are not stable enough after testing. No new code is landed on Aurora, Beta or final, except for those fixes and possible disablings.
Currently FF Nightly is 6. That will become Aurora 6, then Beta 6, and then Firefox (final) 6. The features in all of those should be the same, except that we might fix some bugs along the way and/or disable some features if they are not stable enough after testing. No new code is landed on Aurora, Beta or final, except for those fixes and possible disablings.
No leak in IE6. No leak in FF 3.6.8.
IE6 and FF 3.6 aren't modern browsers :)
Bullshit. Firefox 3.6 was the latest release of FF as recently as two months ago.
not seeing it in Chrome 11.0.698.68.. quitting after 600 requests.
If swap trashing makes a system unusable, why not get rid of the swap and let the program crash? Isn't that the preferred behavior?
This makes sense for servers, because they shouldn't really have any significant amount of virtual memory space tied up by non-resident allocations.
On a desktop OS, the user has a much larger breadth of software loaded and is only using a subset of a handful of software's allocated memory at once. As long as all of that can be in RAM at once, everything else can be safely swapped out without serious performance degradation. The OS can even prefer to swap out long-dormant processes (like, say, the rarely used SSH server on your desktop) to use that RAM for disk cache.
On a desktop OS, the user has a much larger breadth of software loaded and is only using a subset of a handful of software's allocated memory at once. As long as all of that can be in RAM at once, everything else can be safely swapped out without serious performance degradation. The OS can even prefer to swap out long-dormant processes (like, say, the rarely used SSH server on your desktop) to use that RAM for disk cache.
swapping is a fundamental part of a multi-tasking o/s and unfortunately unless a program starts writing into memory addresses that have not been allocated to it the o/s would not be able to know if the program is crashing or not (segmentation faulting)...
to the o/s this bug would just look like a memory hungry program so it just keeps on allocating more memory... once all physical memory has been used up, the o/s has to swap out old data to disk and re-use addresses for this program that just doesn't stop asking for more memory... i.e the program doesn't know it's doing stupid shit and the o/s doesn't know it is hosting a stupid program..
it's kinda like a house party where everyone starts the night normal, then as the night goes on some idiot doesn't recognize their own limits and they keep drinking more and more and the host doesn't know what this guy is doing and before he knows it he has to clean up vomit in the morning...
hope this makes sense..
to the o/s this bug would just look like a memory hungry program so it just keeps on allocating more memory... once all physical memory has been used up, the o/s has to swap out old data to disk and re-use addresses for this program that just doesn't stop asking for more memory... i.e the program doesn't know it's doing stupid shit and the o/s doesn't know it is hosting a stupid program..
it's kinda like a house party where everyone starts the night normal, then as the night goes on some idiot doesn't recognize their own limits and they keep drinking more and more and the host doesn't know what this guy is doing and before he knows it he has to clean up vomit in the morning...
hope this makes sense..
You are conflating virtual memory and swapping. A disk-backed page cache is not necessary for memory protection.
"Browsers are bad at / don't care about constraining website memory usage, news at 11."
[deleted]
[deleted]
[deleted](1)
Haha, the irony.
I dont think this is very ironic. IE9 is native to MSWIN and is written by the people who have the deepest knowledge of the operating system. They probably found this issue and fixed it before it was exposed to the other teams like Goog and Mozilla.
I don't see how the deepest knowledge of Microsoft Windows would help them fight website memory usage issues. Those things are entirely unrelated.
However the reported bug is non-trivial, therefore it would be very strange if it would manifest itself identically on different non-related browsers. They might all leak, but I doubt they all leak 1M for 22kb file.
However the reported bug is non-trivial, therefore it would be very strange if it would manifest itself identically on different non-related browsers. They might all leak, but I doubt they all leak 1M for 22kb file.
1 MB works out at 32 bits per pixel for a 512x512 image. The JPEG is probably not rasterized until it's viewed, which would explain why only an amount corresponding to the compressed image is leaked when the tab is hidden.
>"non-related browsers"
Chrome and Safari both use webkit. Of course that doesn't explain Firefox.
Chrome and Safari both use webkit. Of course that doesn't explain Firefox.
And Opera (which is a "modern browser" too)
The people with the deepest knowledge of the operating system are writing the operating systems (kernel, etc).
I'm not sure what you mean by IE being 'native' to Windows. Regardless of what MS tried to pull 10 years ago, IE being included with Windows does not make it part what the rest of us call the OS. It's an application.
I'm not sure what you mean by IE being 'native' to Windows. Regardless of what MS tried to pull 10 years ago, IE being included with Windows does not make it part what the rest of us call the OS. It's an application.
IE9 also had this bug, but it has been fixed - see http://code.google.com/p/chromium/issues/detail?id=36142#c53
Am I missing some way to install IE9 on XP?