Re: Memory leak in Apple's image handling frameworks ?
___ 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
Re: Memory leak in Apple's image handling frameworks ?
> On May 1, 2023, at 5:04 AM, Gabriel Zachmann wrote: > > Thanks so much again! > > I tried, and it didn't give me a good clue, though. > What I got as output is: > All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1] > 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4] 656[15] 592[2] 528[2] 512[2] > 448[5] 400[3] 384[2] 368[3] 352[1] 336[1] 304[35] 288[19] 272[16] 256[29] > 240[8] 224[6] 208[40] 192[9] 176[15] 160[7] 144[5] 128[7] 112[30] 96[7] > 80[32] 64[115] 48[298] 32[553] 16[130] > 117040KB[25] Thats twenty five 117MB objects. That seems suspicious. Also, if you look further down the heap output to the table of objects look for one or more objects that have a high count that is unexpected. I’d start investigating there. > So that does not account for the 5+GB (after a few minutes, and growing), I > think. At the time you ran heap did it say the 'Physical footprint’ was 5GB? —Rob >> On 30. Apr 2023, at 20:41, Rob Petrovec wrote: >> >> Oh yeah, Gabriel, another technique you can use is to start your app and >> create a memgraph _before_ reproducing the problem. Then reproduce the >> problem and run ‘heap MyApp --diffFrom MyApp.memgraph’. It will show the >> new objects that have been created since the memgraph was taken, sorted >> number of objects. That might narrow down what object(s) are eating your >> memory. Good luck. >> >> —Rob >> > ___ 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
Re: Memory leak in Apple's image handling frameworks ?
malloc is not the only way for your app to leak memory. CGImage in particular allocates its own anonymous VM regions. footprint against your process (man 1 footprint) is a good way to get a quick look at where the system thinks this memory is going. Once you’ve looked at that, Instruments or vmmap or leaks is a good way to further refine your search. Saagar Jha > On May 1, 2023, at 04:04, Gabriel Zachmann via Cocoa-dev > wrote: > > Thanks so much again! > > I tried, and it didn't give me a good clue, though. > What I got as output is: > All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1] > 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4] 656[15] 592[2] 528[2] 512[2] > 448[5] 400[3] 384[2] 368[3] 352[1] 336[1] 304[35] 288[19] 272[16] 256[29] > 240[8] 224[6] 208[40] 192[9] 176[15] 160[7] 144[5] 128[7] 112[30] 96[7] > 80[32] 64[115] 48[298] 32[553] 16[130] > > So that does not account for the 5+GB (after a few minutes, and growing), I > think. > > Best regards, Gabriel > > > > >> On 30. Apr 2023, at 20:41, Rob Petrovec wrote: >> >> Oh yeah, Gabriel, another technique you can use is to start your app and >> create a memgraph _before_ reproducing the problem. Then reproduce the >> problem and run ‘heap MyApp --diffFrom MyApp.memgraph’. It will show the >> new objects that have been created since the memgraph was taken, sorted >> number of objects. That might narrow down what object(s) are eating your >> memory. Good luck. >> >> —Rob >> > > ___ > > 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/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.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
Re: Memory leak in Apple's image handling frameworks ?
Hm, on closer inspection, maybe it did help. At the moment, at least, the memory footprint of my app levels out at 3GB (which would be OK). In any case, thanks again so much to everybody who chimed in! Best regards, Gabriel > On 1. May 2023, at 12:43, Gabriel Zachmann wrote: > > 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 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. >> smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Memory leak in Apple's image handling frameworks ?
Thanks so much again! I tried, and it didn't give me a good clue, though. What I got as output is: All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1] 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4] 656[15] 592[2] 528[2] 512[2] 448[5] 400[3] 384[2] 368[3] 352[1] 336[1] 304[35] 288[19] 272[16] 256[29] 240[8] 224[6] 208[40] 192[9] 176[15] 160[7] 144[5] 128[7] 112[30] 96[7] 80[32] 64[115] 48[298] 32[553] 16[130] So that does not account for the 5+GB (after a few minutes, and growing), I think. Best regards, Gabriel > On 30. Apr 2023, at 20:41, Rob Petrovec wrote: > > Oh yeah, Gabriel, another technique you can use is to start your app and > create a memgraph _before_ reproducing the problem. Then reproduce the > problem and run ‘heap MyApp --diffFrom MyApp.memgraph’. It will show the new > objects that have been created since the memgraph was taken, sorted number of > objects. That might narrow down what object(s) are eating your memory. Good > luck. > > —Rob > smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: Memory leak in Apple's image handling frameworks ?
___ 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
Re: Memory leak in Apple's image handling frameworks ?
Thanks a lot for your response!
I am not sure, though, I understand what you mean.
I've got 3 autoreleasepool's in different places in my source code. They are
just
@autoreleasepool { ... do something ... }
What do you mean by "insufficient use" ? and how do you mean "exit the nearest
autorelease pool block"? is there a problem if I do a 'return' inside an
@autoreleasepool { }
?
(And why should it be a problem whith just one out of 100k+ files? :-) )
Best regards, Gabriel
> On 1. May 2023, at 03:46, Christopher Snowhill 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.
>
smime.p7s
Description: S/MIME cryptographic signature
___
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
Re: Memory leak in Apple's image handling frameworks ?
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
> 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
>> 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 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
> 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.size /
MemoryLayout.size)
let TASK_VM_INFO_REV1_COUNT =
mach_msg_type_number_t(MemoryLayout.offset(of:
\task_vm_info_data_t.min_address)! / MemoryLayout.size)
var info = task_vm_info_data_t()
var count = TASK_VM_INFO_COUNT
let kr = withUnsafeMutablePointer(to: ) { 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, )
}
}
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 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
>> 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.
>>
>>
>>
>> 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
