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
Re: Memory leak in Apple's image handling frameworks ?
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 luck.
>
> —Rob
>
>
>> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev
>> 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
Re: Memory leak in Apple's image handling frameworks ?
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 luck.
—Rob
> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev
> 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
Re: Memory leak in Apple's image handling frameworks ?
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 > On Apr 30, 2023, at 12:31 PM, Rob Petrovec via Cocoa-dev > wrote: > > Hey, > Since you have unbounded memory growth, you will likely have one or > more object types with a TON of instances in the list on the left. They are > likely the source, or part of a chain of objects eating your memory. > MallocStackLogging doesn’t show more info about a possible cause. Once you > find the cause (the object type(s) eating your memory) MallocStackLogging > will show you where those objects are being created and you can inspect their > retain/release history to see where you may be forgetting to release > something. Memory issues are not simple to track down, but once you do find > the cause they are totally satisfying when you find a fix. Good luck. > > —Rob > > >> On Apr 30, 2023, at 9:41 AM, Gabriel Zachmann wrote: >> >> Thanks a lot for your response! >> And thanks a lot for your hints to 'leaks'. >> >> I tried it, but I don't see any "ROOT CYCLE" in the output of 'leaks'. >> (I see a bunch of ROOT LEAKS, but in total it's just 6 kB.) >> >> Also, in the Debugger of Xcode, when i click on "Debug Memory Graph" icon, I >> get lots of graphs, but none of them shows a cycle. >> Same when I double-click the memgraph file: I can select all the memory >> graphs that go through CGImage, but none of them contains a cycle (and most >> of them don't originate in my code). >> >> And, yes, I do release the images using CFRelease() - but, of course, still >> thanks for the thought! >> >> ( I also switched on MallocStackLogging, but that did not provide more info >> on potential causes for the massive leak, of course.) >> >> >> Still stymied, 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory leak in Apple's image handling frameworks ?
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 luck.
>>>
>>> —Rob
>>>
>>>
On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev
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 *
Re: Memory leak in Apple's image handling frameworks ?
Hey, Since you have unbounded memory growth, you will likely have one or more object types with a TON of instances in the list on the left. They are likely the source, or part of a chain of objects eating your memory. MallocStackLogging doesn’t show more info about a possible cause. Once you find the cause (the object type(s) eating your memory) MallocStackLogging will show you where those objects are being created and you can inspect their retain/release history to see where you may be forgetting to release something. Memory issues are not simple to track down, but once you do find the cause they are totally satisfying when you find a fix. Good luck. —Rob > On Apr 30, 2023, at 9:41 AM, Gabriel Zachmann wrote: > > Thanks a lot for your response! > And thanks a lot for your hints to 'leaks'. > > I tried it, but I don't see any "ROOT CYCLE" in the output of 'leaks'. > (I see a bunch of ROOT LEAKS, but in total it's just 6 kB.) > > Also, in the Debugger of Xcode, when i click on "Debug Memory Graph" icon, I > get lots of graphs, but none of them shows a cycle. > Same when I double-click the memgraph file: I can select all the memory > graphs that go through CGImage, but none of them contains a cycle (and most > of them don't originate in my code). > > And, yes, I do release the images using CFRelease() - but, of course, still > thanks for the thought! > > ( I also switched on MallocStackLogging, but that did not provide more info > on potential causes for the massive leak, of course.) > > > Still stymied, 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/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! And thanks a lot for your hints to 'leaks'. I tried it, but I don't see any "ROOT CYCLE" in the output of 'leaks'. (I see a bunch of ROOT LEAKS, but in total it's just 6 kB.) Also, in the Debugger of Xcode, when i click on "Debug Memory Graph" icon, I get lots of graphs, but none of them shows a cycle. Same when I double-click the memgraph file: I can select all the memory graphs that go through CGImage, but none of them contains a cycle (and most of them don't originate in my code). And, yes, I do release the images using CFRelease() - but, of course, still thanks for the thought! ( I also switched on MallocStackLogging, but that did not provide more info on potential causes for the massive leak, of course.) Still stymied, Gab. 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 ?
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 luck.
>>
>> —Rob
>>
>>
>>> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev
>>> 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.
>>>
>>>
>>>
>>>
Re: Memory leak in Apple's image handling frameworks ?
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 luck. > > —Rob > > >> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev >> 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory leak in Apple's image handling frameworks ?
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 luck. —Rob > On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
