Update on Memory Leaks
Posted by John Sullivan on Thursday, September 1st, 2005 at 3:35 pmWe’ve made tremendous progress on fixing memory leaks in the last two weeks. Thanks to everyone who has helped with this effort! Here’s an update on recent activity.
New Tools
We now have two ways to automatically record stack traces for leaks encountered in our standard webkit tests. This is extremely useful since the webkit tests cover many unusual cases that one might not run into during a short browsing session. As we continue to add webkit tests this will continue to test for leaks in more and more corners of the code.
- (Fast) To get a single leaks report covering all webkit tests, use
run-webkit-tests --leaks. You can also pass a specific directory or a specific test to get a leaks report covering just part of the test hierarchy. For examplerun-webkit-tests --leaks dom/html/level1. - (Slow) To get a separate leaks report for each test, use
run-webkit-tests --leaks --singly. Again, you can pass a specific directory to run this on only part of the test hierarchy. This option is much slower, but can be very helpful in pinning down a leak.
Progress Made
A week ago run-webkit-tests --leaks was reporting over 4000 leaks. Today, it usually reports less than five leaks. Many leaks that were found other ways have also been fixed.
Also, the various leak-related bugs reported in Bugzilla have been examined. Many of these reported leaks that are in OS X system software other than WebKit. Bug reports for each of these are now in Radar, Apple’s internal bug system. Some of the other leak-related bugs reported in Bugzilla were duplicates, and these have been marked as such.
Remaining Work
There are still a handful of not yet understood but more-or-less reproducible leaks. Most of these are written up as individual Bugzilla bugs. If you discover any other leaks, please write up new Bugzilla bugs for them.
We will make sure that run-webkit-tests --leaks becomes part of our standard testing procedure. We will also try to track down and fix the remaining few known leaks.
Since the memory leaks found by leaks can depend on subtle differences in configuration, it is still very helpful for anyone who’s so inclined to look for leaks using either run-webkit-tests --leaks or using the steps Maciej outlined in his blog entry from August 16th. We greatly appreciate the help we’ve gotten so far on this, and are always eager for more.
September 2nd, 2005 at 12:53 am
Yay!
Still gives a fuzzy feeling to see some updates from you guys..I really wish Apple would pick up this kind of weblog communication for other Apple apps.
September 2nd, 2005 at 5:09 am
[...] 0
Posted September 2, 2005 2:07 pm in Apple, Software by Dennis
Über 4000 Memory Leaks wurden in Safari gefixt. Das erklärt so einiges.
Momentane Laune:
[...]
September 2nd, 2005 at 9:52 am
Excellent news. 4000 leaks down to 5?!
It’s also excellent that open-sourcing Safari is having a knock-on effect on OS X. So people that aren’t even interested in Safari or WebKit will still benefit in all their other apps.
Good work guys.
Matt
September 5th, 2005 at 5:14 am
I have recompiled Safari this weekend, and the memory usage is way down. I used to see several hundred MBs being used, but I have 6 tabs open and Safari is using only 65MB and it does not seem to be growing. Great work!
Thanks,
DR
September 8th, 2005 at 11:59 pm
Since these leaks effect WebKit, that must mean that all the other Webkit dependent services such as Dashboard Widgets also benefit. That is awesome. Can you give us the process and typical timeline for a build to go to final release to the general Mac user base?
September 29th, 2005 at 4:27 pm
Hi I’m using the default version of Safari 2.0.1 with Saft installed. I would love to see a brief description of how Safari is meant to use memory on various systems. I have 1.5GB on one machine, and find Safari is constantly using hundreds of megs of resident memory, even after closing all windows, and emptying the cache. This isn’t a problem until I run out of ram, and things start paging to disk, at which point I quit and restart Safari to clear up a heap of space.
Does it use as much free memory as it can? When does it (or is it meant to) release the memory back? How big are these memory leaks? Does it only release memory back when the machines runs out of free ram and has to start using swap files? Does emptying the cache empty both the disk cache and the memory cache? Does Safari try to use a percentage of the available ram?
Answers to these questions would help us understand if we are having memory leaks, or if it is simply using what’s available and doing what it should.
Thanks and keep up the good work!
October 1st, 2005 at 9:04 pm
I just posted a screenshot of my machine memory usage with Safari after a few days usage. It demonstrates the excessive memory usage of Safari. My machine is now paging to the hard drive when it doesn’t really need to.
http://pear.co.nz/public/safari_mem_hog.png