On Jun 7, 2013, at 11:44 AM, Jonathan Taylor wrote: > So, wrapping that single line of code in an autorelease pool has fixed it.
> I do think it's interesting though (and a bit worrying) that the only way I > could pinpoint the actual problem was by reading through the relevant bits of > my code over and over - I wasn't able to glean any info from Instruments that > really narrowed things down, other than to confirm that there were definitely > image buffers accumulating somewhere. These two statements contradict each other. The large chunks of memory were not objects or even malloc blocks (probably obtained using vm_allocate() or the like), but they were owned by regular objects. Those regular objects were still alive and keeping the large chunks around. The fact that the use of an autorelease pool fixed the problem is proof of that. So, the Allocations instrument should have been showing you those living objects. True, it couldn't show you the size of memory ultimately dependent on those objects, but that's often the case (i.e. a small object that owns a large NSData or something; Allocations would sort the NSData to the top but you'd have to hunt to find the small object that owns it). You might have had better luck if you had taken heapshots between two points in your app's lifetime and observed what objects had been created after the first and still living at the second. http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ Regards, Ken _______________________________________________ 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
