NEW 16285
Large increase in memory footprint (> 75MB) when loading single page 
https://bugs.webkit.org/show_bug.cgi?id=16285
Summary Large increase in memory footprint (> 75MB) when loading single page
nathan jahnke
Reported 2007-12-03 22:27:22 PST
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)
Comment 1 2007-12-04 02:14:21 PST
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)
Comment 2 2007-12-04 06:08:45 PST
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.
Note You need to log in before you can comment on or make changes to this bug.