Bug 12676 - Safari is holding onto lots of allocated memory when no windows are open
Summary: Safari is holding onto lots of allocated memory when no windows are open
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Geoffrey Garen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-02-06 23:41 PST by Maciej Stachowiak
Modified: 2007-03-14 17:54 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Stachowiak 2007-02-06 23:41:47 PST
2005-05-31 13:55:31 Kevin Armstrong:
* SUMMARY
Safari is allocating a lot of memory and holding onto it after all windows are closed.  Activity Monitor reports Real Memory of 148 MBs and VM of 383 MBs.

* STEPS TO REPRODUCE
1. Boot Tiger 10.4.1
2. Launch Safari
3. Go to sites like cnn, nytimes, slashdot, macrumors, etc.
4. Command click on links to open them in new tabs
5. Read the page and then close the tab to read the next one
6. Repeat step 4 and 5 until all the pages you want to read has been read
7. Close window (so that no windows are open)

* RESULTS
Safari continues to hold on to a large number of objects.

2005-05-31 13:56:34 Nate Begeman:
From the heap and vmmap output, it appears that this is not due to memory fragmentation, but rather holding on to huge numbers of allocated objects with no windows open.

2005-05-31 16:03:36 Marc Sinykin:
Perf BRB:  Not sure how you are using Milestones at this point, but we see this as P2 for Chablis (if not earlier).

This sounds different from the apparently unbounded memory buildup associated with supporting the "Back" button for a given window/tab, since the originator had closed all windows for this report.  Do you know of a bug for the "Back" issue?

2005-08-08 15:40:18 Nate Begeman:
Possible dupe of <rdar://problem/4077814> Gradual slowing down of Safari eventually requiring Quit and relaunch ?

2005-11-13 22:53:51 Marc Sinykin:
Perf BRB:  Please consider for Leopard (or similar timeframe), vs. "Later".

2006-03-07 10:47:20 Alice Liu:
Chris, please try to reproduce, and come up with a more specific plan. thanks. 

2006-03-14 11:34:05 Alice Liu:
Safari Leopard BRB Reviewed

2006-03-20 18:05:06 Chris Petersen:
I can reproduce this both in 10.4.6 and Leopard9A131:

Under 10.4.6 ,  opening 22 tabs created from links at cnn.com results in teh following:

RSIZE: 129 MB
VSIZE: 394 MB

Under 10.4.6 , closing  all of the tabs and window, I still see these ranges:

RSIZE: 81.8 
VSIZE: 376 MB




2006-03-20 18:08:29 Chris Petersen:
With Leopard9A131, I can reproduce the same problem:

After opening 26 tabs created from links at cnn.com, I see the following results in terminal:

RSIZE: 159 MB
VSIZE: 506 MB

Again after closing all tabs and window, a lot of memory is still being allocated to Safari:

RSIZE: 95.5 MB
VSIZE: 486  MB



2006-06-27 11:32:34 Darin Adler:
I'm going to mark various reports of high memory use in Safari after normal usage patterns as duplicates of this bug (except for reports with very precise scenarios or steps to reproduce); we'll use this to be the placeholder for investigation.

2006-10-24 15:50:19 David Harrison:
To Hyatt.

2007-01-03 14:37:09 Darin Adler:
Dave says that we've done a lot about this by fixing bugs in the WebCore cache and also changing the limits on the back/forward cache.

Dave asked me to send this back to Maciej to figure out how the engine team is going to tackle this overall issue.

2007-01-10 15:34:23 Maciej Stachowiak:
The next step here is to narrow the steps to reproduce to a very specific set of steps, and then analyze where the memory use is going, using tools like heap, vmmap, MallocDebug and ObjectAlloc? I would be happy to show anyone how to use these tools.

2007-01-14 10:03:13 Eric Gouriou:
You may be interested by <rdar://problem/4923779> (9A340: 24MB heap & 500kB of leaks after short browsing session + closing unique window) which provides short step-by-step instructions. I do not believe it should be duped to this bug though due to the leaks component.

2007-01-14 12:11:59 Viêt Hoà Dinh:
Though, you should have a look at rdar://4768430
When I tried to make some analysis of Safari memory leaks, I found that main leaks were located in CFURL Cache.

2007-01-14 12:16:57 Viêt Hoà Dinh:
You may be interested by :
http://luxure.corp.apple.com/~hoa/MallocGraph/MallocGraph-9.pkg
(This is an Xray plugin to help leaks analysis)

<rdar://problem/4134977>
Comment 1 Geoffrey Garen 2007-02-08 20:51:06 PST
I'm working on this one.
Comment 2 Dave Hyatt 2007-03-14 17:54:15 PDT
Cache is in really good shape now.