Hi,
This App was an iOS application and previously it handled manual memory
management - mostly using autorelease. I converted it by hand (didn’t use the
ARC coversion process).
As for running the Static Analyser, I did run this and it showed no leaks, but
some dead stores. I have just run it again, and the Static Analyzers now
doesn’t seem to actually do anything? (I’m wondering if this might be a clue?).
I do a “Clean”, then select Analyze. I says it’s Analyzing but stops quite
quicking, I get some yello warnings but no Blue Warnings, and I *know* there
are a couple of Dead-Stores in there!
Part of the code I suspect does things like this:
@property (nonatomic,retain) id
propID;
@property (nonatomic,retain) UIImage
propImage;
@property (nonatomic,retain) UIImage
propDict;
if ([prop1 class] == [UIImage class])
self.propImage = self.pProp1;
if ([prop1 class] == [NSDictionary class])
self.propDict = self.pProp1;
This looked suspect when I saw it, but it seemed to work, so I left as is when
converting to ARC.
Thanks for you help
Dave
On 20 Apr 2014, at 21:04, Quincey Morris <[email protected]>
wrote:
> On Apr 20, 2014, at 11:58 , Cody Garvin <[email protected]> wrote:
>
>> Second, while using instruments use the “mark heap” tool.
>
>> Third, keep in mind that blocks keep strong references to self (especially
>> callbacks).
>
> While these are important debugging steps, I’d suggest that this isn’t the
> place to start *in this case*.
>
> Assuming that this app is being converted from GC (Dave didn’t say so
> explicitly, but presumably conversion from manual RR likely wouldn’t
> introduce these kinds of memory issues), it’s probably better to spend more
> time looking at the source code *before* getting bogged down in debugging.
> There are two kinds of difficult problems that a GC-ARC conversion must
> contend with:
>
> 1. There are patterns of object usage that work fine in GC, but aren’t
> translatable directly into ARC. Specifically, when clusters of objects “go
> away automatically when they are no longer used” under GC, there may be no
> equivalent technique in ARC. (Of course, reference cycles are the underlying
> problematic mechanism, but I’m looking at a higher level.) In particular,
> under ARC it may be necessary to design the app so that it knows explicitly
> *when* such clusters are no longer used, and so can send explicit messages to
> cause the cluster to be deallocated.
>
> 2. Arbitrary object graphs that work fine in GC may be a tangle of
> cross-references in ARC. It may be best to redesign the data model so that
> the objects are strictly (or pretty strictly) hierarchical. That is, to
> change the data model from sibling relationships to parent-child
> relationships**. In other words, to change all the relationships to be “up”
> or “down”, and ensure that all the “up” relationships are weak***.
>
> Both of the above are most effectively done by examining and rearranging the
> source code directly, rather than trying to detect reference cycles in
> Instruments or the debugger, which limit you to a lower design level. A
> thorough source code review should remove *most* of the cycles, and then
> Instruments should help find the ones that are obscure at the source level.
>
>
> ** Of course, if the old data model is enshrined in (say) an archive saved in
> a document, then the app will still need to be able to recognize the old
> model.
>
> *** One resulting gotcha is that weak relationships are *not* KVO compliant,
> and that 10.9 will detect and complain about this, even in cases where 10.8
> and earlier were silent. The original code was probably wrong in some way,
> too, but we often didn’t notice the problem because we tended to just grab a
> big hammer and smash things when closing windows etc. In 10.9, big hammers
> aren’t quite as smashy.
>
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
