[Webkit-unassigned] [Bug 12666] New: Safari reliably grows 3-5 MB per load loading the same (ebay) page

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Feb 6 23:34:24 PST 2007


           Summary: Safari reliably grows 3-5 MB per load loading the same
                    (ebay) page
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Keywords: InRadar
          Severity: Normal
          Priority: P1
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mjs at apple.com

2006-10-16 15:12:04 Marcel Weiher:
Repeatedly loading the same e-bay page (from local disk) reliably causes Safari
memory consumption to reliably grow by around 5MB per page-load (after the
window is closed).

1. Get a debug build of Safari so that 'heap' works.
2. Start this debug build using the WebKit scripts, quit any other running
copies of Safari
3. Run the attached script, pointing it to the files in the attached tarball

After each cycle of "load page, close window", Safari will have grown by about
5MB (sometimes a bit less). This behavior is repeatable for at least 40
iterations (for a total leakage of 200MB), and probably as many as one is
prepared to wait (heap becomes a bit sluggish after a while).

Turning JavaScript off dramatically reduces the leakage, but does not
completely eliminate it.

Monitoring a release build with top shows similar growth.
"leaks" does not show this.
Shark's malloc trace shows various sources of the leaked memory, most notably
ksyyparse() at around 1.8MB per page load.

2006-10-19 16:53:24 Marc Sinykin:
Perf BRB:  Please set milestone and priority.  Sounds like Leopard / P1 if

2006-10-26 12:00:30 Marc Sinykin:
Perf BRB: This bugs needs a Milestone and Priority.  Unless you feel this is
not a real Leopard regression, it should be Leopard/P1.  If you disagree,
please contact me.

2006-11-05 23:06:27 Stephanie Lewis:
Occurs in Leopard 9A300.  Here is the output from the script:

bash-3.1$ ./Desktop/testsafari Desktop/ebay/Apple-Macintosh-Computers.html 
allocatedbase: "11237"
totalbase: 15956
1 2 3 4 5 6 7 8 9 10 
memallocated: 14186
memtotal: 22788
allocated: 14186
allocateddiff: 2949
growthrate: 294
11 12 13 14 15 16 17 18 19 20 
memallocated: 17726
memtotal: 24416
allocated: 17726
allocateddiff: 6489
growthrate: 324
21 22 23 24 25 26 27 28 29 30 
memallocated: 11758
memtotal: 22176
allocated: 11758
allocateddiff: 521
growthrate: 17
31 32 ^C

2006-11-06 11:29:58 Marcel Weiher:
Just a quick note:  a growthrate of 300-500K would represent a 10x improvement
over what I found...or indicate use of a release build.  The script uses the
'heap' tool, which does not pick up memory allocated by the custom allocator in
the release build.

2006-11-09 10:35:01 Alice Liu:
Safari BRB Reviewed - hyatt, would this be fixed by your recent cache changes? 

2006-11-09 11:45:15 Marcel Weiher:
Quick note: this was still happening as of ToT yesterday.  Also, when I sharked
it a lot (but not nearly all) of the still active nodes came from

2007-01-10 15:15:38 Maciej Stachowiak:
Could you attach a report from "leaks" after running with MallocStackLogging?

2007-01-10 15:36:11 Marcel Weiher:
As I mentioned in the description, 'leaks' does not show this.

2007-01-15 14:42:52 Alice Liu:
Safari blocker reviewed

2007-01-15 16:53:38 Maciej Stachowiak:
Another memory leak / growth bug.

2007-01-15 17:13:47 Marcel Weiher:
Absolutely...but with a nice automated script to both reproduce and

2007-01-16 13:20:25 Geoff Garen:
May be the same as http://bugs.webkit.org/show_bug.cgi?id=10773


Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list