Comments on: We’re Hunting Memory Leaks

By: simx

Wed, 02 Nov 2005 01:19:21 +0000

Ummmm… whoops, somehow posted this on the wrong entry. :sheepish: Reposting on the right entry now…

]]>

By: name99

Sun, 18 Sep 2005 06:54:47 +0000

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.

]]>

By: dave_bartlett

Wed, 31 Aug 2005 12:05:00 +0000

2b.
Just come across window.close again @ yahoo.

http://uk.play.yahoo.com/games/close.html

]]>

By: dave_bartlett

Wed, 31 Aug 2005 10:51:56 +0000

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

]]>

By: peterparker

Thu, 25 Aug 2005 00:28:01 +0000

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…

]]>

By: maciej

Wed, 24 Aug 2005 18:43:54 +0000

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.

]]>

By: mardoen

Tue, 23 Aug 2005 15:03:23 +0000

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”?

]]>

By: name99

Fri, 19 Aug 2005 14:23:26 +0000

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”.)

]]>

By: bluea

Thu, 18 Aug 2005 18:09:26 +0000

Is there a way to ‘replay’ the History log? Or enable Applescript recordability?

]]>

By: Matt

Thu, 18 Aug 2005 16:24:15 +0000

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

]]>