Yet another possible issue is that Apple’s frameworks tend to like to hold onto and reuse objects like CALayers. As a result they also hold onto the contents for much longer than you might think. I would at least try imgLayer.contents = nil as soon as you’re sure the layer won’t be displayed again.
Regards, Sandy > On May 1, 2023, at 3:46 AM, Christopher Snowhill via Cocoa-dev > <[email protected]> wrote: > > Another possibility is insufficient use of autorelease pools. Even if you are > freeing your Objective C objects, if you do not exit the nearest autorelease > pool block, they will simply accumulate in the heap. Leak tools will not > consider these to be "leaked" memory. > >> On Apr 30, 2023, at 4:41 PM, Alex Zavatone via Cocoa-dev >> <[email protected]> wrote: >> >> What I tested was if it matched the Xcode memory pie chart across several >> apps. >> >> I can’t remember what results I got with terminal leaks or heap commands. >> >> Add it to one of your programs and give it a shot! Now I’m interested. >> >> Cheers, >> Alex Zavatone >> >>> On Apr 30, 2023, at 1:33 PM, Rob Petrovec <[email protected]> wrote: >>> >>> Curious, Alex, what does this memoryFootprint function show that running >>> ‘footprint’ or ‘heap’ in Terminal doesn’t? >>> >>> —Rob >>> >>> >>>>> On Apr 30, 2023, at 8:12 AM, Alex Zavatone via Cocoa-dev >>>>> <[email protected]> wrote: >>>> >>>> Memory used query method for iOS. >>>> >>>> https://stackoverflow.com/a/57315975/1058199 >>>> >>>> // Created by Alex Zavatone on 8/1/19. >>>> // >>>> >>>> class Memory: NSObject { >>>> >>>> // From Quinn the Eskimo at Apple. >>>> // https://forums.developer.apple.com/thread/105088#357415 >>>> >>>> class func memoryFootprint() -> Float? { >>>> // The `TASK_VM_INFO_COUNT` and `TASK_VM_INFO_REV1_COUNT` macros are >>>> too >>>> // complex for the Swift C importer, so we have to define them >>>> ourselves. >>>> let TASK_VM_INFO_COUNT = >>>> mach_msg_type_number_t(MemoryLayout<task_vm_info_data_t>.size / >>>> MemoryLayout<integer_t>.size) >>>> let TASK_VM_INFO_REV1_COUNT = >>>> mach_msg_type_number_t(MemoryLayout.offset(of: >>>> \task_vm_info_data_t.min_address)! / MemoryLayout<integer_t>.size) >>>> var info = task_vm_info_data_t() >>>> var count = TASK_VM_INFO_COUNT >>>> let kr = withUnsafeMutablePointer(to: &info) { infoPtr in >>>> infoPtr.withMemoryRebound(to: integer_t.self, capacity: >>>> Int(count)) { intPtr in >>>> task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), >>>> intPtr, &count) >>>> } >>>> } >>>> guard >>>> kr == KERN_SUCCESS, >>>> count >= TASK_VM_INFO_REV1_COUNT >>>> else { return nil } >>>> >>>> let usedBytes = Float(info.phys_footprint) >>>> return usedBytes >>>> } >>>> >>>> class func formattedMemoryFootprint() -> String >>>> { >>>> let usedBytes: UInt64? = UInt64(self.memoryFootprint() ?? 0) >>>> let usedMB = Double(usedBytes ?? 0) / 1024 / 1024 >>>> let usedMBAsString: String = "\(usedMB)MB" >>>> return usedMBAsString >>>> } >>>> } >>>> Enjoy >>>> >>>> >>>> >>>>> On Apr 30, 2023, at 9:05 AM, Alex Zavatone <[email protected]> wrote: >>>>> >>>>> Use the memory graph debugger, not Instruments. >>>>> >>>>> I also have a method published on StackOverflow that lets you check on >>>>> and print out the amount of memory used. It is for iOS. >>>>> >>>>> As for abandoned memory, that also could be the case. An object in >>>>> memory with no pointer to it. >>>>> >>>>> If you want, we could do a video meeting and I could guide you through >>>>> it. >>>>> >>>>> Will reply with the memory querying function. >>>>> >>>>> Cheers, >>>>> Alex Zavatone >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Apr 29, 2023, at 11:15 PM, Rob Petrovec via Cocoa-dev >>>>>> <[email protected]> wrote: >>>>>> >>>>>> This sounds like Abandoned Memory, not a leak. Abandoned memory is a >>>>>> retain cycle somewhere. Best/easiest way to find those is with a >>>>>> memgraph. Click the little sideways V icon in Xcode’s debugger when the >>>>>> problem is reproducing. >>>>>> <PastedGraphic-1.png> >>>>>> >>>>>> >>>>>> Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the problem is >>>>>> reproducing and open the resulting .memgraph file in your home >>>>>> directory. Bonus points is enabling MallocStackLogging in the Xcode >>>>>> Project -> Edit Scheme -> Run -> Diagnostics and check Malloc Stack >>>>>> Logging and switch to All Allocations And Free History. This will show >>>>>> backtraces for where an object is created in the memgraph and other >>>>>> useful info. >>>>>> >>>>>> Leaks show up as little yellow caution signs and abandoned memory >>>>>> sometimes have purple caution signs. Either way, look for an abnormally >>>>>> high number of objects and see if they point back to your image. Thats >>>>>> likely where your memory is being consumed. >>>>>> >>>>>>> CGImageSourceCreateWithURL() for loading, CALayer for displaying. >>>>>> Just a thought since you didn’t mention it: are you releasing the >>>>>> CGImageSource object too? >>>>>> >>>>>> Good luck. >>>>>> >>>>>> —Rob >>>>>> >>>>>> >>>>>>> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> I have an app that is basically a slide show. >>>>>>> Basically, it loads one image after another, displays it, then frees up >>>>>>> its memory. >>>>>>> When I test it with my image collection of 100k+ images, everything is >>>>>>> fine. >>>>>>> >>>>>>> However, one user sent me a photo (JPG) that makes my app use up more >>>>>>> and more memory. >>>>>>> I can see it in Activity Monitor and in Xcode's Memory Report View. >>>>>>> After a minute, my app uses 5 GB of main memory, after that, the growth >>>>>>> rate slows down a bit, >>>>>>> but it keeps growing without bounds, until, eventually, it crashes, of >>>>>>> course. >>>>>>> >>>>>>> However, when I try to check for memory leaks using >>>>>>> XCode/Instruments/Leaks, it says there are none! >>>>>>> >>>>>>> Is it possible there is a memory leak in Apple's frameworks? >>>>>>> >>>>>>> If you are interested, you can find the image here: >>>>>>> https://owncloud.informatik.uni-bremen.de/index.php/s/BbBJcjMSTm9enwW >>>>>>> It's just 5 MB, and I can't see any issue with it. >>>>>>> The uncompressed image in-memory maybe takes up 100MB. >>>>>>> >>>>>>> The frameworks/methods I use are the usual: >>>>>>> CGImageSourceCreateWithURL() for loading, CALayer for displaying. >>>>>>> >>>>>>> I assign the image like this: >>>>>>> >>>>>>> CALayer * imgLayer = [CALayer layer]; >>>>>>> imgLayer.contents = (__bridge id)(imageRef); >>>>>>> >>>>>>> where imageRef is of type CGImageRef. >>>>>>> I also release my images later with CGImageRelease(). >>>>>>> >>>>>>> I am a stymied. >>>>>>> Any hints/suggestions will be highly appreciated. >>>>>>> >>>>>>> Gab. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> Cocoa-dev mailing list ([email protected]) >>>>>>> >>>>>>> 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/petrock%40mac.com >>>>>>> >>>>>>> This email sent to [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Cocoa-dev mailing list ([email protected]) >>>>>> >>>>>> 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/zav%40mac.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>> >>>> _______________________________________________ >>>> >>>> Cocoa-dev mailing list ([email protected]) >>>> >>>> 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/petrock%40mac.com >>>> >>>> This email sent to [email protected] >>> >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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/chris%40kode54.net >> >> This email sent to [email protected] > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/mcguffogl%40gmail.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
