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 <quinceymor...@rivergatesoftware.com> 
wrote:

> On Apr 20, 2014, at 11:58 , Cody Garvin <c...@servalsoft.com> 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 (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

Reply via email to