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 
> <cocoa-dev@lists.apple.com> 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 
>> <cocoa-dev@lists.apple.com> 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 <petr...@mac.com> 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 
>>>>> <cocoa-dev@lists.apple.com> 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 <z...@mac.com> 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 
>>>>>> <cocoa-dev@lists.apple.com> 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 
>>>>>>> <cocoa-dev@lists.apple.com> 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 (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/petrock%40mac.com
>>>>>>> 
>>>>>>> This email sent to petr...@mac.com
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 
>>>>>> 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/zav%40mac.com
>>>>>> 
>>>>>> This email sent to z...@mac.com
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 
>>>> 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/petrock%40mac.com
>>>> 
>>>> This email sent to petr...@mac.com
>>> 
>> 
>> _______________________________________________
>> 
>> 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/chris%40kode54.net
>> 
>> This email sent to ch...@kode54.net
> 
> _______________________________________________
> 
> 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/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@gmail.com

_______________________________________________

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

Reply via email to