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.
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.
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. :)
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.
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.
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.
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 .
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.
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.
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.
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).
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)?
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.
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.
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...
I'm not sure where you got that from, but just so everybody's clear, this leak isn't in Flash — it's somewhere in the browsers' image loading code. Odd that an identical bug would be present in both Chrome and Firefox.
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.
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.
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.
Am I missing some way to install IE9 on XP?