Re: quartz-wm memory usage
Re: quartz-wm memory usage
- Subject: Re: quartz-wm memory usage
- From: "David Walthour" <email@hidden>
- Date: Wed, 14 Nov 2007 21:21:31 -0600
Based upon the output of heap (see below) that it looks like mostly
NSCFString and NSCFData objects. These are the objects that increment
in count between successive runs of rdesktop.
I am certain that there are no instances of rdesktop that haven't really died.
I know the string leak looks harmless but given that:
A. this leak did not happen at startup of X11.app or quarz-wm, but
instead happened during a later point when quartz-wm had been running
for a while when I was starting up a particular instance of rdesktop
B. it is strings that are dominating the abnormal memory growth of quartz-wm
I am not so quick to write off that memory leak as harmless or
unrelated to the primary problem.
I should point out here that rdesktop itself is very well behaved and
extremely stable. It is not the problem. quartz-wm has the problem.
Here is the output of running 'heap quartz-wm':
Process 759: 1 zone
Zone DefaultMallocZone_0x44000: Overall size: 44088KB; 203780 nodes
malloced for 37261KB (84% of capacity); largest unused:
[0x13a40400-5886KB]
Zone DefaultMallocZone_0x44000: 203780 nodes - Sizes: 24KB[3] 20KB[49]
16KB[2] 8KB[147] 4KB[1] 4KB[3] 2048[5] 1536[8] 1024[9246] 512[5]
480[2] 448[4] 432[2] 384[5] 368[2] 304[27393] 288[3] 272[27393]
256[22] 240[2] 224[7] 208[4] 192[8] 176[8] 160[7] 144[16] 128[37]
112[35490] 96[27] 80[51567] 64[16079] 48[16642] 32[17610] 16[1981]
Found 1802 ObjC classes in process 759
Found 47 CFTypes in process 759
-----------------------------------------------------------------------
Zone DefaultMallocZone_0x44000: 203780 nodes (38155168 bytes)
CLASS_NAME TYPE
BINARY COUNT BYTES AVG
========== ====
====== ===== ===== ===
NSCFString ObjC
CoreFoundation 100295 16807296 167.6
NSCFData ObjC
Foundation 99216 19803888 199.6
<non-object>
3711 1513120 407.7
NSCFDictionary ObjC
Foundation 112 7360 65.7
NSCFArray ObjC
Foundation 79 2816 35.6
__NSCFDate ObjC
CoreFoundation 62 992 16.0
NSCFTimer ObjC
Foundation 61 4816 79.0
NSCFNumber ObjC
Foundation 47 752 16.0
NSURL ObjC
Foundation 28 896 32.0
NSCFSet ObjC
Foundation 16 1024 64.0
CFBag CFType
CoreFoundation 12 768 64.0
NSMachPort ObjC
Foundation 11 704 64.0
CFRunLoopSource CFType
CoreFoundation 10 640 64.0
CFXPreferencesPropertyListSource ObjC
CoreFoundation 9 576 64.0
CFXPreferencesSearchListSource ObjC
CoreFoundation 7 224 32.0
CGSRegion CFType
CoreGraphics 6 96 16.0
NSRecursiveLock ObjC
Foundation 5 400 80.0
(anonymous namespace)::BuiltinIntegerType C++
libGLProgrammability.dylib 5 240 48.0
CFXPreferencesSource ObjC
CoreFoundation 5 80 16.0
LSASN CFType
LaunchServices 5 80 16.0
NSMergePolicy ObjC
CoreData 5 80 16.0
CFXPreferencesManagedSource ObjC
CoreFoundation 4 256 64.0
NSLock ObjC
Foundation 4 256 64.0
llvm::Type C++
libGLProgrammability.dylib 4 192 48.0
_NSStateMarker ObjC
AppKit 4 128 32.0
CFRunLoopMode CFType
CoreFoundation 3 144 48.0
SCService C++
CarbonCore 3 96 32.0
icu::UCharCharacterIterator C++
libicucore.A.dylib 3 96 32.0
NSCFLocale ObjC
Foundation 3 80 26.7
VolFSMount C++
CarbonCore 2 896 448.0
SCClientSession C++
CarbonCore 2 288 144.0
CFMessagePort CFType
CoreFoundation 2 160 80.0
CFNotificationCenter CFType
CoreFoundation 2 64 32.0
DADisk CFType
DiskArbitration 2 64 32.0
NSConcreteMutableData ObjC
Foundation 2 64 32.0
__NSPlaceholderArray ObjC
CoreFoundation 2 32 16.0
__NSPlaceholderDictionary ObjC
CoreFoundation 2 32 16.0
__NSPlaceholderSet ObjC
CoreFoundation 2 32 16.0
Not A Type CFType
CoreFoundation 1 4096 4096.0
icu::Locale C++
libicucore.A.dylib 1 160 160.0
CFSocket CFType
CoreFoundation 1 128 128.0
_NSThreadData ObjC
Foundation 1 96 96.0
x_screen ObjC
quartz-wm 1 96 96.0
CFBundle CFType
CoreFoundation 1 80 80.0
CGEventSource CFType
CoreGraphics 1 80 80.0
NSNotificationCenter ObjC
Foundation 1 64 64.0
NSThread ObjC
Foundation 1 64 64.0
CFRunLoop CFType
CoreFoundation 1 48 48.0
NSPasteboard ObjC
AppKit 1 48 48.0
NSPathStore2 ObjC
Foundation 1 48 48.0
NSRunLoop ObjC
CoreFoundation 1 48 48.0
RemoteCacheable C++
CarbonCore 1 48 48.0
AuthClient C++
Security 1 32 32.0
CFPasteboard CFType
CoreFoundation 1 32 32.0
CFUUID CFType
CoreFoundation 1 32 32.0
DASession CFType
DiskArbitration 1 32 32.0
NSAutoreleasePool ObjC
Foundation 1 32 32.0
NSProcessInfo ObjC
Foundation 1 32 32.0
NSUserDefaults ObjC
CoreFoundation 1 32 32.0
x_selection ObjC
quartz-wm 1 32 32.0
CFXPreferencesCompatibilitySource ObjC
CoreFoundation 1 16 16.0
DefaultAllocator C++
Security 1 16 16.0
NSPlaceholderString ObjC
Foundation 1 16 16.0
Security::ExecutableTool C++
Security 1 16 16.0
__NSPlaceholderDate ObjC
CoreFoundation 1 16 16.0
On Nov 14, 2007 8:47 PM, Greg Parker <email@hidden> wrote:
>
> On Nov 14, 2007, at 6:20 PM, David Walthour wrote:
> > However this is a very old message. I have continued to see this
> > problem in Tiger's X11 and now Leopard's X11. I wish I knew what
> > caused it. I just will suddenly realize that the quartz-wm process
> > is eating up a huge amount of ram and it forces me to shut it down.
> > For a long while I switched from quartz-wm to blackbox as my window
> > manager under Tiger because this problem was interfering too much
> > with my work, but I would prefer to get quartz-wm to be stable
> > because of its ability to interleave X11 windows with Mac windows.
> >
> > It seems the leak is fairly bad when I am running rdesktop to remote
> > to a windows box. When running this app, quartz-wm (not rdesktop)
> > is growing by at least 800KB. For example, the following is the
> > output of two successive runs of leaks on quartz-wm. Notice in the
> > first run, quartz-wm has already leaked two strings of 32 bytes
> > each. In between the two successive runs, I connected to my windows
> > box with rdesktop. After doing so, quartz-wm has grown by about
> > 800kb and this 800kb is never released.
> >
> > Macintosh:~ dwalthou$ leaks quartz-wm
> > Process 759: 131224 nodes malloced for 11402 KB
> > Process 759: 2 leaks for 64 total leaked bytes.
> > Leak: 0x320a20 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
> > Leak: 0x12efbfe0 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
> > Macintosh:~ dwalthou$ leaks quartz-wm
> > Process 759: 139616 nodes malloced for 12236 KB
> > Process 759: 2 leaks for 64 total leaked bytes.
> > Leak: 0x320a20 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
> > Leak: 0x12efbfe0 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
>
> That string leak looks harmless. It's likely to be simple sloppiness
> during startup, and never hurts anything further.
>
>
> > Also, the amount that it grows by varies each time I run rdesktop
> > because after I closed rdesktop and ran it again, I saw this output
> > from leaks showing that quartz-wm had grown by another 9MB:
> >
> > Macintosh:~ dwalthou$ leaks quartz-wm
> > Process 759: 148896 nodes malloced for 21531 KB
> > Process 759: 2 leaks for 64 total leaked bytes.
> > Leak: 0x320a20 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
> > Leak: 0x12efbfe0 size=32 string '_NET_WM_WINDOW_TYPE_NORMAL'
>
> Make sure rdesktop really is closing when you do this. Use `top` to
> look for old copies of rdesktop that didn't really die.
>
> Some tools besides `leaks` that might help indicate where the memory
> went:
> * `heap quartz-wm`. This shows object types and block sizes for
> allocations in the process. Useful for before-and-after comparisons,
> especially if you see something like "the number of NSImages goes up
> by 20 every cycle".
> * `vmmap quartz-wm`. This shows the raw virtual memory map for the
> process. Useful for identifying memory increases that aren't in malloc
> memory (like window buffers).
> * Quartz Debug (in /Developer/Applications/Graphics Tools). First
> "Show Window List", then look for quartz-wm windows that are created
> and never destroyed every cycle.
>
>
> --
> Greg Parker email@hidden Runtime Wrangler
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden