Re: Unconventional memory leak problem
Re: Unconventional memory leak problem
- Subject: Re: Unconventional memory leak problem
- From: Rodney Kennedy <email@hidden>
- Date: Wed, 6 Sep 2006 22:08:57 +1000
On 06/09/2006, at 1:57 PM, Matt Neuburg wrote:
On Wed, 6 Sep 2006 09:56:38 +1000, Rodney Kennedy <email@hidden>
said:
I have something that appears like a memory leak with the
culprit allocations are related to drawing interface objects
such a NSTableView in 4 or so windows. This is a problem
when I run in a batch mode which induces a considerable amount of
screen drawing including rendering images. The odd thing is
when I interact with the running Application, such as click on
a window or activate or deactivate the application this induces
the AppKit deallocations. If I leave it alone as the active
application or it is not active the real and virtual memory uses
rise and the application will eventually crash.
This is not like a conventional memory leak since there are
deallocations.
I do run multiple threads
You probably just need autorelease pools:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
MemoryMgmt/Concep
ts/AutoreleasePools.html>
I'm quite confident with NSAutoreleasePool and use them on secondary
threads. (I have
extensively used them and understand them.)
The symptom does act like accumulating autoreleased objects in a big
loop for which you would
use a NSAutoreleasePool even on the main thread. Trouble is I don't
have a big loop (not
explicitly at least; it is complicated by a sequence of
Notifications; ... actually it is a loop
because I have processing blocks "connected" through NSNotifications).
Also using ObjectAlloc I can see that the culprit allocations are not
objects I allocate but are
induced by NSTableView drawRect .... drawing gridlines. So the
AppKit is creating the
autoreleased objects (unidentified 2K blocks on an Intel machine and
1K blocks on
a PowerPC).
Suppose these are autoreleased objects them I'd assume they would be
released at the end of the
event loop. (I think I assume the event loop chugs away even when
there is no real events.) It seems
when I do get a real event like a mouse click then the main thread
NSAutoreleasePool is released
and the memory is reclaimed. That is very close what I see or
believe is happening.
So to summarize; I have quite a lot of processing which induces
considerable drawing on the main
thread and the AppKit seems to be generating 1000's of autoreleased
objects but these don't get
released unless the application gets an "event". (My app does very
serious amounts of processing
such as the processing of 100,000 images, so normal apps may not
strike this problem.)
I think I see the light at the end of the tunnel. At the very least
I think I know how to completely
rewrite the processing so it may work.
Perhaps I can periodically send mock events to keep the event loop
turning over. (How do you do this?)
Also I just saw Tom's post. I think the morale is you don't just
have to be diligent about
memory management of "your" objects (which I'm pretty good at) but
also objects you may induce.
Then again why do I need to clean up after AppKit? Also I assumed
performSelectorOnMainThread
would trigger the event loop.
You might also have to recache each image when done with it, in
order to
force the image to deallocate fully (sorry I'm a bit hazy on this -
not
meaning, "I've forgotten," but meaning, "I've never been quite
clear on the
best procedure"). m.
I'll look into that
Rod
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
Rodney Kennedy
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden