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: Gabriel Zachmann via Cocoa-dev <email@hidden>
- Date: Mon, 1 May 2023 12:43:56 +0200
Thanks a lot for the hint!
I tried it, but it did not change anything in the behavior of the app.
Best regards, Gabriel
> On 1. May 2023, at 09:54, Sandy McGuffog <email@hidden> wrote:
>
> 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
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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