Summary: | World leaks seen on Leopard after opening then closing tab | ||
---|---|---|---|
Product: | WebKit | Reporter: | Mark Rowe (bdash) <mrowe> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Major | CC: | ejalbert |
Priority: | P1 | Keywords: | InRadar |
Version: | 523.x (Safari 3) | ||
Hardware: | Mac | ||
OS: | OS X 10.4 | ||
URL: | http://xn--sailor-183m.com/dvds/ |
Description
Mark Rowe (bdash)
2007-03-12 21:21:56 PDT
Bugzilla mangled the URL. It is <http://xn--sailor-183m.com/dvds/>. This is definitely memory held by the WebCore cache. The cache is massively underreporting its size... I think this could be related to the already-filed bugs against ImageIO holding on to tons of memory in the image source. I landed a fix to account for the larger encoded data. On my machine everything is behaving more or less as expected now. The WebCore cache is 128mb on very large memory machines. The encoded size error was making it take more like 200mb. When I close the window now on Tiger, the cache is properly full at 128mb. So even though this looks like a giant "leak", all that has happened is that single page filled up the entire cache. Over time the cache shouldn't grow but should stay at that maximum size. Fixed committed by hyatt in r20139. http://trac.webkit.org/projects/webkit/changeset/20139 That fix doesn't address the WebDataSource and WebHTMLRepresentation leaks I'm seeing. The world leaks dialog may be a red herring. I've seen cases where the TOT world leaks timer fires too soon, and checks for deallocation before all cleanup has happened. You can test for this by opening and closing an empty window after you see a world leak report. That will cause the world leak check to fire again. The world leaks issue seems to be Leopard-only, so I'm going to close this Bugzilla as fixed but continue to track the world leaks issue in the associated Radar. |