Bug 16285
Summary: | Large increase in memory footprint (> 75MB) when loading single page | ||
---|---|---|---|
Product: | WebKit | Reporter: | nathan jahnke <njahnke> |
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | mrowe |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac (Intel) | ||
OS: | OS X 10.5 | ||
URL: | http://nate.quandra.org/sda_pms.html |
nathan jahnke
1) open safari
2) load http://nate.quandra.org/sda_pms.html
3) load about:blank (optional)
4) close window (optional)
5) open a new window (optional)
6) browse anything else (optional)
MINI:~ njahnke$ leaks Safari
Process 32021: 1106877 nodes malloced for 91505 KB
Process 32021: 2 leaks for 48 total leaked bytes.
Leak: 0x746190 size=32 instance of 'NSCFString', type ObjC, implemented in CoreFoundation
0xa048b4a0 0x0100078c 0x616a6e07 0x656b6e68 ..H......njahnke
0x00000000 0x00000000 0x00000000 0x00000000 ................
Call stack: [thread 0xa0573f60]: | 0x2876 | NSApplicationMain | +[NSBundle(NSNibLoading) loadNibNamed:owner:] | +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] | +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] | loadNib | -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] | -[NSIBObjectData instantiateObject:] | objc_msgSend | _class_lookupMethodAndLoadCache | _class_initialize | 0x2a4e | CRCopyCrashHistory | _CRCopyCrashHistoryPath | SCDynamicStoreCopyConsoleUser | SCDynamicStoreCopyValue | _SCUnserialize | CFPropertyListCreateFromXMLData | _CFPropertyListCreateFromXMLData | __CFTryParseBinaryPlist | __CFBinaryPlistCreateObject2 | __CFBinaryPlistCreateObject2 | __CFBinaryPlistCreateObject2 | __CFBinaryPlistCreateObject2 | CFStringCreateWithBytes | __CFStringCreateImmutableFunnel3 | _CFRuntimeCreateInstance | malloc_zone_malloc
Leak: 0x20fab970 size=16 instance of 'TSMInputSource', type CFType, implemented in HIToolbox
0xa044fec0 0x0e014f80 0x00000006 0x00000000 ..D..O..........
Call stack: [thread 0xa0573f60]: | 0x2876 | NSApplicationMain | -[NSApplication run] | 0x324a8 | -[NSApplication sendEvent:] | 0x329d3 | -[NSWindow sendEvent:] | 0x351e4 | 0x355e7 | -[NSTextView mouseDown:] | -[NSTSMInputContext handleMouseEvent:] | TSMProcessMouseEvent | TSMEventToKeyboardInputMethod | TSMEventToInputMethod | SendTSMDocumentLockEvent | SendTSMEvent | SendEventToEventTarget | SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) | DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) | _NSTSMEventHandler | +[NSInputContext currentInputContext] | -[NSTSMInputContext _activate] | ActivateTSMDocument | MyActivateTSMDocument | utOpenActivateThisDocsInputMethod | IMKInputSessionSetProperty | -[IMKInputSession setValue:forTag:] | _CF_forwarding_prep_0 | ___forwarding___ | -[NSDistantObject forwardInvocation:] | -[NSConnection sendInvocation:internal:] | CFRunLoopRunInMode | CFRunLoopRunSpecific | __CFMachPortPerform | __NSFireMachPort | -[NSConcretePortCoder dispatch] | -[NSConnection handlePortCoder:] | -[NSConnection handleRequest:sequence:] | -[NSConnection dispatchInvocation:] | -[NSInvocation invoke] | __invoking___ | _CF_forwarding_prep_0 | ___forwarding___ | -[NSInvocation invokeWithTarget:] | -[NSInvocation invoke] | __invoking___ | -[IMKInputSession selectInputMode:] | TISCreateInputSourceList | TSMCreateInputSourceRefForIndex | CreateInputSourceForIndex | _CFRuntimeCreateInstance | malloc_zone_malloc
MINI:~ njahnke$
leak is much bigger - as stated in the summary, ram rsize on the safari process is over 100 meg and stays there forever after loading http://nate.quandra.org/sda_pms.html .
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
David Kilzer (:ddkilzer)
I think you're probably seeing the result of images being loaded into the image cache and persisting after the web page is closed.
Mark Rowe (bdash)
Firstly, the RSIZE figure is not as useful for measuring memory usage as RPRVT. When I refer to memory use below, I'll be referring to the latter.
I don't see 100MB of growth. With system Safari on 10.5 I see the following:
Startup: 4316K
Load page: 84M
Close window: 84M
Empty WebCore cache: 78M
This suggests that around 6MB of RAM was being used by decoded image data in the memory cache, and was freed when the cache was emptied. The fact that the memory use after performing these steps is higher than at startup is expected and does not mean that a leak has occurred.
Memory allocators request large slices of memory from the system at a time to fulfill the allocations that an application requests. When the application is finished with the memory, it returns it to the memory allocator. It is up to the allocators discretion whether the memory is returned to the system. Poking around inside Safari after following the scenario above, I see that the majority of the RPRVT figure can be accounted for by memory marked as free inside WebKit's memory allocator. This supports my statment that no leak has occurred. The memory held by the memory allocator will be used to fulfill future requests before requesting more RAM from the system.
The memory allocator used throughout WebCore doesn't return free memory to the system very aggressively. I think what you're seeing here is simply a symptom of that, rather than a leak in the normal sense.