2006-10-16 15:12:04 Marcel Weiher: * SUMMARY 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). * STEPS TO REPRODUCE 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 * RESULTS 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). * REGRESSION Turning JavaScript off dramatically reduces the leakage, but does not completely eliminate it. * NOTES 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 true. 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 ksjsyyparse(). 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 instrument... 2007-01-16 13:20:25 Geoff Garen: May be the same as http://bugs.webkit.org/show_bug.cgi?id=10773 <rdar://problem/4786230>
Please add the attachments as referenced in the bug report.
Created attachment 13268 [details] the script mentioned
Created attachment 13269 [details] the tarball mentioned
Fixed in Radar.