On Oct 15, 2013, at 17:22:26, Graham Cox <graham....@bigpond.com> wrote:
> OK, so if that's the case, I'm interested in knowing whether each call to > -itemArray returns the same object or a different one each time. If it's > different, then it's either a copy of some internal array or something built > on the fly. It's a different object - like I mentioned, it's an __NSArrayI* where the member variable of NSMenu is an __NSArrayM*, and the addresses are indeed different. What's pissing me off right now is that I can't reproduce it again, and I haven't changed any code (the couple tests I made have been reverted). Ack! I'm going to try adding a signal flag to the method that calls itemArray that was previously showing the hundreds of arrays being copied so I can narrow right down to that code in the Allocations trace. *time passes* Ah, here it is again. So here's the section of allocations between the first and last call to itemArray. Nearly all of these are caused by a call to itemArray: Graph Category Live Bytes # Living # Transitory Overall Bytes # Overall # Allocations (Net / Overall) 1 * All Allocations * 524.55 KB 8448 165275 80.14 MB 173723 <XRRatioObject: 0x7fb11094e640> %0.02, %0.34 That shows over 8000 of these pointers are still living, and I know there aren't 8000 menus. Here's a typical stack for most of the calls to itemArray: 0 libsystem_c.dylib calloc 1 libobjc.A.dylib _class_createInstanceFromZone 2 libobjc.A.dylib _class_createInstance 3 CoreFoundation __CFAllocateObject2 4 CoreFoundation +[__NSArrayI __new:::] 5 CoreFoundation -[__NSPlaceholderArray initWithObjects:count:] 6 CoreFoundation -[NSArray initWithArray:range:copyItems:] 7 CoreFoundation -[NSArray initWithArray:copyItems:] 8 CoreFoundation -[__NSArrayM copyWithZone:] 9 libobjc.A.dylib -[NSObject copy] 10 AppKit -[NSMenu itemArray] 11 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:] 12 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:] 13 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:depthFirst:] 14 Finale 2014 -[NSMenu(FCExtensions) itemWithTag:searchSubmenus:] 15 Finale 2014 MenuEnable(EMENU, long, bool) 16 Finale 2014 FinPlugIn::AdjustMenuItems(EMENU, bool) const 17 Finale 2014 FinPlugInList::AdjustMenuItems(EMENU, bool) const 18 Finale 2014 FXMI_AdjustMenuItems(EMENU, bool) 19 Finale 2014 -[FinaleAppDelegate validateMenuItem:] 20 AppKit -[NSMenu _enableItem:] 21 AppKit -[NSMenu _enableItems] 22 AppKit -[NSMenu update] This is running our release target. Zombies is off. Am I just not reading this data correctly? These do NOT appear as leaks in the Leaks instrument, only as allocations in the Allocations instrument. If I run this particular code over and over, I can watch the app's memory footprint grow steadily, yet Leaks shows nothing out of the ordinary. > So that might lead you to look at how and where these methods are being > called, e.g. sure they're on the main thread, within a runloop event handler > of some sort? The main run loop and some modal loops that are started and ended for a modal dialog I was using to exercise some code. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
