Re: Finding AS related memory leak
Re: Finding AS related memory leak
- Subject: Re: Finding AS related memory leak
- From: Antonio Nunes <email@hidden>
- Date: Wed, 9 Jul 2008 15:40:46 +0100
Taking this back to the list, as I think it came off by mistake...
On 9 Jul 2008, at 14:56, John C. Daub wrote:
It's difficult to say what the problem IS, but I can suggest a few
things to
look at:
on 7/9/08 1:48 AM, Antonio Nunes at email@hidden wrote:
When the script runs, the code in my app that gets called is:
- (id)unstyledTextForScripting
{
return self.string;
}
It seems you are using the Objective-C 2.0 properties, so I would
check what
your properties are set to... minding how things are retained or
copied or
assigned. This may lend some clues.
The class where this method exists is a subclass of PDFPage. "string"
is one of the superclass's ivars. I'm just passing it through, and
assume PDFPage does the right thing. Further, the app is garbage
collected, so retain and release should be non-issues.
to get the text of a PDF page, and:
- (NSArray *)pages
{
if (masterArray == nil || masterArray.document !=
self.masterPDFDocument) {
masterArray = [[ANPDFClerkPagesArray alloc] init];
masterArray.document = self.masterPDFDocument;
}
This is one that made me wonder... what is the state/properties of
this
"masterArray". For instance, if it's set to retain, this is going to
leak
because you've alloc/init'd, and then the assignment to masterArray
would
retain (so now it's theoretically got a retain count of 2).
ANPDFClerkPagesArray exists the gain access to the pages in a PDF
document that is an ivar in my NSDocument subclass. It simply
overrides the two required methods for NSArray subclasses:
-------- -------- -------- -------- --------
@interface ANPDFClerkPagesArray : NSArray <NSFastEnumeration> {
PDFDocument *document;
}
@property (assign) PDFDocument *document;
-------- -------- -------- -------- --------
@implementation ANPDFClerkPagesArray
- (NSUInteger)count
{
return document.pageCount;
}
- (id)objectAtIndex:(NSUInteger)index
{
return [document pageAtIndex:index];
}
...snip...
@synthesize document;
@end
-------- -------- -------- -------- --------
As you can see, it basically acts as a proxy array for the pages in a
PDFDocument. It doesn't create or hold on to anything.
As well, what happens in the case of masterArray not being nil but the
masterArray.document not being self.masterPDFDocument? That will
cause a new
ANPDFClerkPagesArray to be allocated and the old one left to the
ether. Of
course again, much of this depends upon what the state/properties of
masterArray are... retain/assign/copy, do you have explicit get/set
accessors for that, etc..
masterArray is not implemented with properties or any kind of
accessors. It's only ever accessed directly and only in the "pages"
method listed above. The implementation would leak if the app were not
garbage collected, but since it is, when a new array replaces the old
one, the old one no longer has a strong reference to it and becomes
collectable. Furthermore this situation doesn't occur in the course of
the script at hand, so we are guaranteed that the "pages" method is
always returning the same array. It only gets created once, so we're
not leaking an array on each run through the loop. Personally I think
we're leaking a CFString on each iteration, but since I'm not that
comfortable yet around ObjectAlloc and Leaks and Shark etc. I csn't be
sure.
António
--------------------------------------------
I try to take one day at a time, but sometimes, several days attack me
all at once!
--------------------------------------------
_______________________________________________
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