Re: Memory leak in Apple's image handling frameworks ?
Re: Memory leak in Apple's image handling frameworks ?
- Subject: Re: Memory leak in Apple's image handling frameworks ?
- From: Sandy McGuffog via Cocoa-dev <email@hidden>
- Date: Mon, 1 May 2023 09:54:01 +0200
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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden)
>>>>>>>
>>>>>>> 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:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> Cocoa-dev mailing list (email@hidden)
>>>>>>
>>>>>> 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:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden)
>>>>
>>>> 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:
>>>>
>>>> This email sent to email@hidden
>>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden