Re: CALayer contents memory leak
Re: CALayer contents memory leak
- Subject: Re: CALayer contents memory leak
- From: Matt Neuburg <email@hidden>
- Date: Tue, 04 Nov 2008 15:00:04 -0800
- Thread-topic: CALayer contents memory leak
On Tue, 04 Nov 2008 08:58:24 -0700, Adam Fedor <email@hidden> said:
>
>On Nov 4, 2008, at 8:23 AM, Matt Neuburg wrote:
>
>> On Sun, 02 Nov 2008 22:08:04 -0700, Adam Fedor <email@hidden> said:
>>> I have a simple program with a memory leak that is driving me crazy.
>>> It's basically a slide show application (no I can't use IKSlideShow),
>>> where I repeatedly set an image in a CALayer. When run, the app
>>> increases in memory size by 10MB or so every time a new image is
>>> displayed.
>>
>> This is NOT evidence for a leak. Do not attempt to second-guess that
>> Mac OS
>> X virtual memory management system. In fact, do not guess. The only
>> way to
>> know whether you have a leak is to use the memory analysis tools
>> (MallocDebug, Shark, what have you). m.
>>
>
>I have used ObjectAlloc and MallocDebug. In ObjectAlloc you can see
>the graph of memory usage go up like a stair-step ad infinitum.
"Memory usage" is not a leak. "ad infinitum" is not measurement. The above
statement by you is not an example of "using" these tools. You should be
able to say: at moment 1, I have these objects; at moment 2 (presumably
after setting an image), I have these objects, and this particular object
right here should have been released and isn't. You can even say, if you are
using the tools right, exactly where the object got allocated and who puts
retains on it. Until you can say that such-and-such an action of the
application is allocating an object and at such-and-such a later time it
should have been released but was not, you don't have a leak. You're just
flying by the seat of your pants.
I will give two examples of phenomena that sound like yours but are not
leaks:
(1) Repeatedly opening large files from disk. This causes the memory
management system to map to those areas of disk. I had this problem in an
application that read many (say 100) large (say 30 MB each) image files from
disk and drew their thumbnails into a window. It was a problem, but it
wasn't a leak, and fixing it had to with the fcntl settings, not Cocoa
memory management.
(2) Repeatedly doing just about anything, even where memory is managed
correctly in theory, but where the event loop never idles so autorelease
pools are never cleaned up. For example I had an app that read some data and
manipulated some strings. Each intermediate string in the manipulation was
autoreleased by Cocoa, but when there was a LOT of this data, memory usage
grew until the application broke down. This was because autorelease is no
good to you unless the pool is actually released, and the pool is not
released until idle time. Putting in my own autorelease pool in the loop and
releasing it myself solved the problem. Again, this was not a leak; memory
was being managed correctly. It's just that there were too many objects
accumulating at one time.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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