Bug 18555

Summary: Large memory consumption by web inspector on long running pages (like gmail overnight)
Product: WebKit Reporter: Eric Roman <eroman>
Component: Web Inspector (Deprecated)Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ain, aroben, burg
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
repeatedly load images into a hidden DIV none

Description Eric Roman 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
Comment 1 Eric Roman 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.
Comment 2 Timothy Hatcher 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>
Comment 3 Ain Tohvri 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.