RESOLVED FIXED 18555
Large memory consumption by web inspector on long running pages (like gmail overnight) 
https://bugs.webkit.org/show_bug.cgi?id=18555
Summary Large memory consumption by web inspector on long running pages (like gmail o...
Eric Roman
Reported 2008-04-17 14:05:41 PDT
InspectorController::didLoadResourceFromMemoryCache() copies the request/response headers into its resources table. This can add up to lots of memory, especially when the same image is requested continually. The end result is that for long running pages (like leaving gmail running overnight) _lots_ of memory can get chewed up. I am attaching a test case which can quickly chew memory in the (windows) Safari 3.1
Attachments
repeatedly load images into a hidden DIV (3.44 KB, text/html)
2008-04-17 14:16 PDT, Eric Roman 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Eric Roman
Comment 1 2008-04-17 14:16:40 PDT
Created attachment 20637 [details] repeatedly load images into a hidden DIV On windows, enable the safari "developer menu", then launch this test and click "run" (note: it is not necessary to open the inspector itself to repro) Observe that the memory consumption of Safari.exe rises very quickly (0.5mb/sec for my settings) The test is repeatedly setting the innerHTML of a display:none DIV. Each time with the same images, so they are served out of the cache. However, their headers are copied into the inspector's resource list each time! Eventually my safari crashes. I tried running this test on mac os x safari 3.1 (also with developer menu enabled), but could not get this problem to repro (same thing if webinspector is actually opened before/during the test. I tried re-proing on a windows webkit nightly, but the test and inspector didn't seem to even be working, so the outcome is inconclusive.
Timothy Hatcher
Comment 2 2008-04-17 14:36:39 PDT
Bug 18223 represents the fact that we keep track of a resource multiple times, even if it is loading from the cache. When that bug is fixed, that would break this test, since we would only keep one copy of the headers. Granted, there is still a problem here where memory is consumed and we need to come up with a design to solve this. <rdar://problem/5290193>
Ain Tohvri
Comment 3 2008-10-02 03:47:24 PDT
I confirm this on r37126. Goes as high as there is to go which for me is somewhere around 1.2 GB. This is a developer show stopper.
Note You need to log in before you can comment on or make changes to this bug.