WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
6438
Google Reader creates AJAX-related memory leak
https://bugs.webkit.org/show_bug.cgi?id=6438
Summary
Google Reader creates AJAX-related memory leak
Thomas F. O'Connell
Reported
2006-01-08 17:27:09 PST
I regularly use Google Reader as my RSS/Atom/XML feed reader. The functionality is fully supported in Safari, but when I go far enough back in time, Safari uses an incredible amount of memory. I am currently paged down to about 1500 items in the feed history, and this is what I get from top -o rsize: COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE Safari 0.5% 1:57:35 9 272 2328 265M 93.6M 263M 3.36G This is reproducible with Safari Version 2.0.2 (416.13).
Attachments
Add attachment
proposed patch, testcase, etc.
Thomas F. O'Connell
Comment 1
2006-01-15 20:52:49 PST
More information on my typical usage pattern: I typically scroll through hundreds of feeds in a given sitting, often paging through several hundred to find a starting point. As I scroll through the feeds, the headlines and abstracts are grabbed by Google and rendered by Safari, and I'll open and close stories in a new window dozens of times conditionally during the scrolling based on the abstract. It doesn't take long with this usage pattern to push Safari over 1 GB of total address space allocated.
Thomas F. O'Connell
Comment 2
2006-01-15 20:53:28 PST
Oh, and by the way, Safari is now Version 2.0.3 (417.8).
Doug Jones
Comment 3
2006-03-08 07:31:38 PST
I'm not so sure this is actually a memory leak. I used MallocDebug and analyzed a build from the most recent source and no significant leaks were reported. I did notice memory similar to what you have reported, however it seems like this might be a result of the large number of Javascript objects needed to build the Google Reader page. Large memory usage does not necessary mean that any memory is being leaked. Perhaps a better question to ask is whether that much memory is needed.
Thomas F. O'Connell
Comment 4
2006-03-08 09:22:39 PST
Fair assessment. Then the question becomes why that memory isn't reclaimed when I close my browser window.
Doug Jones
Comment 5
2006-03-08 12:25:25 PST
(In reply to
comment #4
)
> Fair assessment. Then the question becomes why that memory isn't reclaimed when > I close my browser window. >
This is a guess on my part, but I would say that this might be due to the behavior of malloc and Mac OS X's implementation of it. When the os increases the size of an application's heap (where dynamic memory comes from) it doesn't necessarily reclaim that memory once free is used. Instead, it may still be allocated for that application's heap even though it is not in "use" and tools such as top or ps will report it as such. Perhaps someone who has more knowledge of memory management on OS X can confirm this for me.
Joost de Valk (AlthA)
Comment 6
2006-07-12 10:20:32 PDT
Adding GoogleBug keyword in one big change.
Sanjay Madhav (chmmravatar)
Comment 7
2007-01-21 02:39:53 PST
I can confirm that this issue still occurs with ToT (even including the fix for 10773). JS object usage increases quite a bit through use of the page. You don't even have to scroll; just subscribe to two feeds, and keep switching back and forth between those feeds. After the feed changes, hit GC collect, and you'll see the JS total objects go up by several thousand every time. If you close out the browser window and hit GC collect, JS object count does hit 0, so this does not appear to be the same issue that gmail has.
Maciej Stachowiak
Comment 8
2007-01-29 03:44:58 PST
<
rdar://problem/4960636
>
Geoffrey Garen
Comment 9
2007-03-13 23:50:45 PDT
Because of the sheer number of page loads, many different factors are in play here. Let me try to break things down. First, a gotcha: The original bug was filed using an older version of Safari *and* an older version of Google Reader. I tested Safari 2.0.4 (419.3), TOT Debug, and Firefox 1.5 with the latest Google Reader, then checked for discrepancies using the older Google Reader and TOT Release. The only significant discrepancy to report is that it's impossible to scroll all the way to 1500 messages using the new Google Reader -- it's just too slow to load. However, I couldn't get anything interesting to happen simply by scrolling to 1500. Factor 1: JavaScript objects. Tested by swapping between 2 text-only feeds (Reuters: Business, Reuters: Oddly Enough). 10.4.8 Stock Safari: - live JS object count grew by 1000s of objects per load - RPRVT grew ~1100K per load - ~7K JS objects remained uncollectible after closing the window TOT: - live JS object count grew by 1000s of objects per load (notably, the only objects explicitly protected from GC were Functions) - RPRVT grew ~850K per load - 0 JS objects remained uncollectible after closing the window FF: - RPRVT grew ~700K per load Conclusions: (1) Safari 2.0 suffered from a JavaScript GC memory cycle, fixed in TOT. (2) JS objects are more memory efficient in TOT than in Safari 2.0. (3) Google Reader creates an unbounded set of event listeners. This seems like a Google Reader bug. (4) Firefox is more memory efficient than TOT executing Google Reader JS. Without more specific data, I'm not going to read much into that, since we know that Google often serves Safari and FF different content, and you could write a whole web browser in the time it would take to plow through their obfuscated JS. Factor 2: WebCore object cache. Tested with cache size set to 4 MB (WebKitObjectCacheSizePreferenceKey set to 1048576 on a 2GB system). Test 1: Scroll through aggregate of cars, tech, photo, and video subscriptions. Test 2: Inside news subscription, open, load, scroll all around in, then close each page as you come to it, up until the China tech page. 10.4.8 Stock Safari: Test 1: RPRVT grew > 150 MB Test 2: RPRVT grew to 58 MB* TOT Debug: Test 1: RPRVT grew > 150 MB Test 2: RPRVT grew to 41 MB* FF: Test 1: RPRVT grew > 150 MB * I don't think this number was very accurate, because many per-page allocations depend on timing -- how long an animation runs, what JS executes, etc. Conclusions: (1) Google Reader loads an infinite stream of resources into a single document. This is pathological behavior, but real, so we probably want to work out a way to throw off-screen resources away in extreme situations. I've filed <
rdar://problem/5061904
> about that. (2) We know that Safari 2.0 had a bug with unbounded growth in the memory cache. With so many page loads, it was probably a factor, but I can't prove that conclusively. Factor 3: Other leaks. Because of its custom allocator, Safari 2.0 doesn't lend itself to leak checking with the 'leaks' tool. I didn't see any significant leaks with TOT Debug. Factor 4: External fragmentation. For the most part, an application's RPRVT number does not shrink from a high water mark. Your process's heap takes memory from the system but doesn't give it back. We're considering ways to improve that (<
rdar://problem/4990356
>). Factor X: VSIZE The original report shows 3.3 GB VSIZE. First, that's insane! You're moments away from running out of address space completely. Second, you show only 256 MB RPRVT, which makes me wonder what's taking up all that VSIZE. I was never able to reproduce the huge VSIZE with low RPRVT result. We believe that Safari 2.0 leaked plug-in streams. If you were playing lots of video, that may have been a factor. FWIW, I see more RPRVT and VSIZE growth in Safari 2.0 than in TOT when playing a single YouTube video in the RSS view. It's tough to say if that's a leak or just fragmentation. Also, you may have been seeing a Safari 2.0 bug that was fixed as of 2.0.4. So, to recap: This bug is a mixture of unreproducible issues, reproducible issues that have been fixed, and reproducible issues that are tracked through independent bug reports. I'd be happy to field another Google Reader bug report with a very specific set of steps to reproduce a very specific leak. Otherwise, I think I've done is as much as I can do with this general report, so let's close it.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug