We’re Hunting Memory Leaks
Posted by Maciej Stachowiak on Tuesday, August 16th, 2005 at 10:24 pmWe’ve heard a number of reports of Safari memory leaks, and we’d like to fix a bunch of these. This is a very important factor for usability of Safari and other WebKit apps. You can help! Here’s how:
Finding Leaks
The Mac OS X Developer Tools include a very useful program for leak detection. Here’s how you can use it:
- Get a fresh WebKit build, ideally a Development build as this turns off the various custom allocators in WebKit.
- Set the MallocStackLogging environment variable to YES (in bash,
export MallocStackLogging=YES, in tcsh,setenv MallocStackLogging YES). - Run Safari using
run-safari - Browse around a little
- From the command line, run
leaks Safari
At this point, if you found memory leaks, the leaks program will tell you how many, and give stack traces for each. You can file this report, along with a description of what steps you took to get the leak, in bugzilla. Put “LEAK:” at the start of the title so these bugs are easy to find.
If you want to make an even better bug report, see if you can reproduce the leak by following some specific set of steps, and include that in the bug. You can also look at the backtraces in the leak report and see if you can match up ones that look the same. It’s useful to file a separate bug report for each one that looks different, and to consolidate leaks on different sites that look like they have the same stack trace.
Fixing Leaks
Fixing memory leaks is a bit of a black art. The leak checker will tell you where the leaked memory was allocated, but not why it was never freed. Sometimes it will be obvious from code inspection that there is no free call to match a particular allocation. Other times, things get trickier – especially when refcounting is involved. In that case, you often know that
some code is holding an extra ref without releasing it, but it can be very hard to tell what code.
Here’s a trick I have often found useful for these situations. Fire up the app in gdb. Set breakpoints on the appropriate ref and deref methods. Then, use the gdb “commands” feature to set commands of “bt 10; cont” for these breakpoints. You’ll get a 10-frame backtrace for every ref and deref, and that’s often enough to find the one that doesn’t pair up.
Destroy All Leaks
If you want to help with finding and fixing leaks, and you need more advice, stop by #webkit on freenode. Happy hunting.
August 17th, 2005 at 2:03 am
Well, I’m sure you guys and gals know this already, but spend half an hour on the Apple discussion boards at http://discussions.info.apple.com/webx?14@878.6Ceca3xL2F0.196363@ , preferably accessing things like “my posts” or other search related activity and you will very soon find some nasty memory leaks.
Most people find that the ‘Real RAM” consumption of Safari goes up from a a few megabytes to over 200MB within 20 minutes or so., at which time very nasty slowdowns occur (40 secs to a minute to open a link on the pages, despite my 1500 ADSL link and an iMac G5 2 GHz with 2 gig of RAM. The problem causes these slowdowns even when I have more than a Gig of RAM completely free.)
A number of Apple Discussion Board Level 4’s have been discussing this problem and reporting exactly the same experience. We hav been wondering whether to blame you, Apple , Javascript, or Web Crossing. Many people who use this board regularly are simply shifting to other browsers to avoid the problem.
The leak can be overcome to a large extent by disabling javascript, but this is a very annoying way to have to deal with the issue. Spend half an hour on these boards and I’m sure you will soon get some relevant information!
Cheers
Rod
August 17th, 2005 at 10:23 am
Thanks for the suggestion, Rod. One reason we are making this effort is because we’ve heard many complaints about leaks and growing memory use. At this point, the most helpful additional info is specific reproducible cases of memory leaks. I understand your frustration, we are doing our best.
August 17th, 2005 at 12:01 pm
I have noticed one memory leak, although I haven’t been able to get a specific instance reproducable as yet. My wife and I have almost identical systems, both running 10.4.2, and we both use Safari extensively. I almost never have any problems with memory leaks and the like, while she can’t go for more than an hour or so without having to quit Safari and restarting due to memory leaks, and this is on a system with 768MB RAM. We visit almost the exact same sites, but the one notable difference is that she frequents a bulletin board powered by vBulletin. I will try the above steps ASAP to see if I can trace the exact leak, but it seems at least plausible that there’s something about vBulletin-formatted pages that causes memory leaks in Safari. Just throwing this bit out there in case someone else notices a correlation with their leaks.
August 17th, 2005 at 4:49 pm
i have been complaining about “simple” defects like memory leaks & crashing in safari for years (via the bug & crash reporter).
nothing has changed.
let alone the features requested!
so, for stability i use firefox and for features i use omniweb (though the momentum behind moz extentions/plugins makes the ‘incrementalist’ advantage of cocoa look hard to beat).
apple is simply not expending the efforts to create a state-of-the-art (let alone practical!) browser.
too bad, i was a safari enthusiast at first (precisely the people that apple cant afford to lose!)
August 18th, 2005 at 9:24 am
I know this isn’t the right place to do this…but…I haven’t learnt how to search and use BugZilla properly yet.
Anyway, the latest builds have two visible acid2 errors;
1. The nose changes to blue on mouseover
2. The eyes are gone
zahadum, that isn’t really a constructive post is it. It’s especially ironic that one thing you’re complaining about is now a big focus of the team. If the defects are so “simple” how about pulling the code and making some beneficial changes yourself? I’m sure they’d be delighted if you solved just one memory leak, and of course Apple wouldn’t lose you then.
Matt
August 18th, 2005 at 11:09 am
Is there a way to ‘replay’ the History log? Or enable Applescript recordability?
August 19th, 2005 at 7:23 am
Is the problem as simple as memory leaks?
I haven’t used Safari 2.0 enough to comment, but with 1.3 (and earlier) in addition to simple memory leakage there seems to be some sort of ever growing fragmentation of all memory structures. This obviously shows up in the (frequently complained about) fact that Safari starts off zippy and then over time (for me with a half-life of about a week) slowly gets slower and slower and so so so slow. But more interesting is that, once it has reached this slow state where every action takes 30 seconds to perform, when you quit the app the quitting takes about a minute. Interestingly, this extremely slow shutdown occurs even if you close every window before you choose quit from the menu.
It’s hard to see how memory leakage per se could lead to such a slow shutdown. It really seems more like some critical data structures are based on perhaps linked lists that get insanely fragmented, with a bazillion dead nodes in the middle of the list, or a hash that goes wrong and hashes EVERYTHING to the same number.
My point is that,
(1) while it is always good to kill memory leaks, it’s not clear to me (via informal monitoring of my memory usage and paging through menumeters) that it is memory leakage and VM swappage per se that is slowing Safari down.
(2) it would be worth your while, I think, and probably easier than many alternatives, to investigate what is going on when Safari is quit in the simplest case of having no windows open. Write some code to count various operations, conditional on some variable that only gets set when the user chooses quit, and try to track what is going on at this point and just why it takes so long. (Obviously you want to do this after Safari has been used for a few days or weeks so that it has switched to “slow mode”.)
August 23rd, 2005 at 8:03 am
The nature of the comments here makes me wonder if this site wouldn’t be well-advised to have a user questions/bug discussion forum.
Or how about something similar to what Asa is doing on his blog: “Ask Asa”?
August 24th, 2005 at 11:43 am
name99: There may also be non-leak memory growth or fragmentation. Certainly, if there is, we would like to fix it. But since this kind of thing is much harder to detect with tools, we are focusing on memory leaks first.
That being said, it would be helpful if you could provide any of the following: (1) specific steps to reproduce “slow mode” (just saying “run it for a few days” is not enough – not everyone visits the same web sites or uses the browser in the same way, and so far no one on the Safari team is regularly encountering this sort of “slow mode”); (2) a profile made with Shark.app (included in the developer toos) taken while browsing and while quitting when Safari is in this bad state. Bug reports with that kind of info would help us a lot.
August 24th, 2005 at 5:28 pm
I wish I had time to participate in this because I spend a lot of time in the Apple discussion forums and Safari’s real memory just keeps going higher while I’m in there. But… the worst part is that with JavaScript enabled almost any link on the Apple site takes a good full second before it even attempts to start loading the page after clicking on it. Disable JavaScript, and voila the same links load normally. That one stinks…
August 31st, 2005 at 3:51 am
I don’t have the developer tools on my machine but there are two “world leaks” than Safari 1.3.1 tells me about.
Perhaps someone with dev tools could test these against a current Safari build and update bugzilla if they’re still current?
1. BBC world service
http://www.bbc.co.uk/radio/aod/worldservice_promo.shtml
a) load page
b) click “listen live”
c) close page > “world leak detected”
2. window.close()
This page describes a repeatable leak with window.close()
http://lists.apple.com/archives/Web-dev/2005/Jan/msg00003.html
August 31st, 2005 at 5:05 am
2b.
Just come across window.close again @ yahoo.
http://uk.play.yahoo.com/games/close.html
September 17th, 2005 at 11:54 pm
Hi maciej,
In followup to your requests, I have submitted a bug in bugzilla (5035).
I can’t see any way to attach the shark report to the bug. Please mail me telling me how to get it to you.
November 1st, 2005 at 6:19 pm
Ummmm… whoops, somehow posted this on the wrong entry. :sheepish: Reposting on the right entry now…